You are on page 1of 2

GENERALIZING THE SPUFS CONCEPT – A CASE STUDY TOWARDS

A COMMON ACCELERATOR INTERFACE

Andreas Heinig1 , Jochen Strunk1 , Wolfgang Rehm1 , Heiko Schick2
1
Chemnitz University of Technology, Germany
2
IBM Deutschland Entwicklung GmbH, Germany
{heandr,sjoc,rehm}@informatik.tu-chemnitz.de, schickhj@de.ibm.com
corresponding author: Andreas Heinig, phone (+49)179 9101345

This research is supported by the Center for Advanced Studies (CAS) of the IBM Boeblingen Laboratory, Germany as
part of the NICOLL Project.

The development of specialized application accelerators is happening today. However,
they do not share a common attach point, and have no common architecture or program-
ing model. A framework that economically and efficiently enables specialized acceleration
is highly desirable.

In this work we propose a generic interface concept called ”ACCFS” for integrating ap-
plication accelerators into Linux-based platforms. The idea is to extend the programing
model chosen by the Linux for Cell/B.E. team. On the Cell/B.E. multiple independent
vector processors called Synergistic Processing Units (SPUs) are built around a 64-bit
PowerPC r
core (PPE). The programing model is to create a virtual file system (VFS) to
export the functionality of the SPUs to the user space via a file interface, they called it
”SPUFS”. Against other solutions such as using character devices or introducing a new
process space the VFS interface uses common file system calls and provides an economic
and efficient access to the accelerator units, the SPUs.
User Level

application application

libspe * libacc **

system call interface system call interface

libfs RSPUFS concept libfs

accfs **
Kernel Level

device handler

device handler

device handler
proc

proc
ext2

ext2

ACC **

ACC **

ACC **

... spufs * ...

Character / Network / Block Character / Network / Block
device drivers device drivers
Hardware Level

S S S S S S A A A
PPE P P ... P CPU PPE P P ... P CPU C C ... C
U U U U U U C C C

Cell/B.E. CPU: case study Opteron ACCelerator: e.g. FPGA
starting point: SPUFS concept intermediate generalization step target: ACCFS concept

* **
Figure 1: Extending the SPUFS concept to ACCFS

1
We have had the idea to check out whether this approach could be adopted successfully
to a more generic coupling of a CPU and accelerators. Therefore we have chosen a step-
by-step porting. In a first step we replaced the PPE by a commodity main stream CPU
– in that case AMD Opteron. A further step will be the substitution of the SPUs by
other specialized accelerators such as FPGAs and the like.

Figure 1 illustrates the stepwise generalization starting with the SPUFS concept followed
by an intermediate step (”RSPUFS”) that finally leads to the ACCFS concept.

The SPUFS concept virtualizes the SPUs. Therefore SPUFS manages a context for each
virtual SPU with all the necessary data for suspending and resuming SPU program exe-
cution. For manipulating the context and the eventually bounded physical SPU a virtual
file system interface is provided. The contexts are bounded on a physical SPU by a
scheduler inside SPUFS. All this work is done by the ”spufs” kernel driver on the PPE.

The first step towards a common accelerator file system was to prove that the PPE can
be replaced by another processor. In our case we chose an AMD Opteron. As there
was no hardware solution available that enables direct coupling of an Opteron proces-
sor with SPUs we use an Ethernet-based coupling as intermediate step. In conjunction
with our Remote SPUFS (RSPUFS) implementation a direct coupling could be emulated.
RSPUFS consists of two parts. The first is a Linux kernel driver with the name ”rspufs”.
It runs on the Opteron side and provides the same VFS interface as SPUFS. The second
is a proxy like daemon named ”rspufsd” executed as user-space program on the Cell.
This daemon translates the network requests from rspufs into the appropriate SPUFS
virtual file system calls.

We could prove that it is possible to cope with problems like byte ordering (endianes)
and direct memory access (even emulated) without modifying the SPUFS concept.

Furthermore the RSPUFS implementation shows a way for integrating accelerators other
than SPUs by splitting the functionality into two parts: one abstracting the user inter-
face (rspufs) and one integrating the acceleration hardware (rspufsd). We propose exactly
this structure for the ACCFS concept. The upper half of ACCFS provides the virtual
file system interface and the bottom manages the vendor specific parts of the accelerator
components. The interface between them has to support a wide variety of accelerators
like FPGAs, GPUs or DSPs. It also has to provide a basic function set comprising at
least functions for the manipulation of memory, the register file and DMA units, and for
signaling and mailboxing.

Currently we are working on an enhanced specification of an interface within the context
of various accelerator integrations in conjunction with tight coupling using HyperTrans-
port Technology (Torrenza) and direct system bus connections as well.

In this paper we describe SPUFS and the current RSPUFS implementation. Finally we
give an outlook on ACCFS.

2