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

Standard Linux tools can also be used for bitstream compression:

$ gunzip –c bitstream.gzip > /dev/icap

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

#!/bin/sh

for i in “1 2 3 4 5”; do

wget –O /dev/fpga${i} / bitfile${i}.bit done;

Figure 3. Shell script to automatically retrieve remote bitstreams and configure FPGAs

Extending the filter coefficient example from before:

$ gunzip –c bitstream.gzip |

set_coeffs 0.1 0.4 0.4 0.1 > /dev/icap

These examples show how complex operations may be performed by chaining multiple tools and utilities.

C. Networking and remote bitstream servers

We may easily leverage the other benefits of using a proper operating system – for example seamless integration of networking services. The “wget” command issues HTTP and FTP requests to remote servers. The following one-liner requests a bitstream (“partial.bit”) from a remote server ( for this example) and performs reconfiguration:

$ wget –O /dev/icap

ftp:///partial.bit

If our bitstream server is more intelligent, and can dynamically generate bitstreams according to some specified parameters, we can picture something like the following, to fetch an encryption module, dynamically specialised according to some parameters (the URL has been wrapped due to the short line length):

$ wget –O /dev/icap

/bitfile? mod_type=encrypt&param=…

Yet another possibility is that the bitstream server is implemented locally, such as would be the case for a purely endo-reconfigurable system. By utilising standard networking services, no change would be required to the client software:

$ wget –O /dev/icap

http://localhost/bitfile? mod_type=encrypt&param=…

#!/bin/sh

# configure the driver hardware

cat conf_bus_driver.bit > /dev/icap

# load the kernel driver insmod conf_bus_driver.o

# configure the slave FPGAs for i in “1 2 3 4 5”; do

wget –O /dev/fpga${i} / bitfile${i}.bit done;

Figure 4. Shell script to dynamically load FPGA logic for configuring external FPGAs, and kernel module for device driver support Simply substituting localhost as the server name is all that is required – the operating system takes care of the rest.

D. Self configuring FPGA arrays

We have so far considered the concept of a single FPGA and Microblaze system, managing its own reconfiguration. However, the concepts scale elegantly to the notion of FPGA arrays, with either a hierarchical configuration management strategy, or even a distributed/cooperative approach. As previously mentioned, the ICAP is simply an internal interface to the FPGA configuration subsystem. The device driver approach presented here could just as easily be layered over an external configuration bus, used to configure arrays of FPGAs.

By exploiting the Linux device driver concept of major and minor device numbers, specific FPGAs in such a system could be assigned a particular minor number. The minor number would be used to control a chip-select signal on the configuration bus, and the configuration data streamed as appropriate. The shell script in Figure 3 would initiate the reconfiguration of an array of five FPGAs, connected to this “master” FPGA. In this example the bit streams are served remotely. Note that the logic resources used by the master to configure other FPGAs are not required all of the time, so one might consider the approach of first swapping in the configuration bus driver hardware, followed by dynamically loading the device driver, as in Figure 4.

This shows how our approach permits thinking about the problem at a much more abstract level. E. Readback and configuration verification

A small C program based on the readback algorithm presented in Section III.C was written. This is a very simple tool, taking as parameters the block, major and minor frame numbers (a

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

configuration frame address), and producing as output an ASCII representation of the configuration memory.

Such a tool makes it very easy to write programs and scripts to read back and verify the contents of the FPGA. The Xilinx implementation tool bitgen can produce as output a mask file that indicates which bits in a bitstream should be verified in a readback. Thus, by converting this mask file into the appropriate ASCII format, a readback and verification can be achieved with a simple readback followed by a comparison.

Action taken as a result of a successful or unsuccessful readback is application specific, but would likely involve reconfiguration using mechanisms like those described above.

Building on the idea of the previous section, using the same logic interface to the configuration of external FPGAs, a master device can very easily perform readback and verification of other FPGAs in a system.

V. Discussion

In the following we present discussion on some relevant aspects of the proposed approach that have not been previously addressed.

A. Performance

A performance price is always paid for the useability gained by higher level abstractions. Indeed, by choosing uClinux as the platform for our RSoC research, we accept the performance cost in exchange for the tremendous leverage offered by such a comprehensive platform.

In terms of the ICAP device and driver, the performance overhead is modest. Bitstream data is generated by an application (either dynamically, read from a file, or from a network connection). It is then sent to the kernel via the write() system call, which requires it to be copied once from user space to kernel space.

After being received by the kernel, the data is then copied into the OPB ICAP device’s local memory. Finally, when the reconfiguratio …… 此处隐藏：5691字，全部文档内容请下载后查看。喜欢就下载吧 ……