Space-Time Processing&mdash;Linux Style

Developing a new generation of wireless communications means you need FPGA development tools, a cluster for simulation and an embedded OS for prototype devices. Linux fits the need.

Here at Tait Electronics Group Research in Christchurch, New Zealand, we
quietly have been building an advanced wireless networking concept called
space-time (ST) processing. ST is predicted by many to drive the next
big-step improvement in wireless technology after 3G. The nature of space-time
is that the mathematics behind it and, consequently, its implementation,
are extremely complex. Many academic researchers are working on this,
but we have completed two world-first practical implementations on our
ST array research (STAR) platform. These are time-reversal
space-time block coding (TR-STBC) and the tongue-twisting single
carrier, adaptive multivariate decision feedback equalised multiple-in,
multiple-out (SC-AMV-DFE-MIMO) coding scheme. Without a doubt, these
achievements were possible
largely thanks to the performance and adaptability of Linux.

This article describes how Linux was key in enabling our mathematical
simulations and was adopted for our embedded processing and runtime control.
We cover such diverse aspects as message passing interface (MPI),
cluster computing, embedded Linux, PHP, shell scripts, network filesystem (NFS), SMB (server message block) and kernel modules on ARM,
Alpha and Intel architecture computers. We skip development details,
but describe the system as it operates today, highlighting some of
the real advantages we gained by using Linux.

In its basic configuration, each STAR platform consists of one
multichannel transmitter unit and one multichannel receiver unit,
both connected to a shared LAN and transmitting anything up to around
200Mb/s at microwave frequencies. There actually are 23 printed
circuit boards in each unit, which took 15 people a year to design
and build.

Figure 1. A bidirectional RF link uses one
multichannel transmitter and one multichannel receiver
on each STAR platform.

Figure 1 shows the system wired to a shared Ethernet as a bidirectional
RF link. The setup shown is for experimental purposes; an actual product
would not have a shared Ethernet between transmitter and receiver.

All of the clever radio processing is done on the digital board, not
by the ARM processor but by a dedicated field programmable gate array
(FPGA) and digital signal processor (DSP). We call FPGA code firmware
because we can't decide whether it's software or hardware; this way
we don't have to comply with either the software coding standards or
the hardware design standards of the company. In the middle of
last year, when we designed the system, we used the biggest, fastest
and most expensive FPGA and DSP we could obtain, and we since have added two
more big FPGAs. The ARM is not used for low-level processing because
we require over 50,000MIPS for ST processing.
With this complexity, even the fastest components alone are not enough,
so we decided early on to build a multiprocessor-capable system.

STAR units are extensible through high-speed low-voltage differential
signaling (LVDS) connections that run at up to 1Gb/s. Each board has
two sets of five-channel bidirectional LVDS interconnects to link two
neighbouring boards. At the same time, each board is wired to Ethernet.
High-speed data travels over LVDS, and control data uses Ethernet.

Development

Most processing occurs in the FPGA, coded in VHDL. A growing number of
VHDL tools are available for Linux (see sidebar), and we used Quartus
from Altera.
In our system, we developed algorithms first with GNU-Octave and then ported
them to VHDL. Octave and the mostly compatible MATLAB
are available for Linux and Microsoft Windows, but Octave has an MPI-enabled version that runs on clusters. We compiled
this for a cluster of old DEC Alphas we call zion. MPI-Octave really
screams on zion despite the fact that the fastest CPU is only 500MHz.

For our digital board, we used an ARM Linux toolchain from handhelds.org
to compile freshly patched 2.4.18 kernel sources.
Russell King began ARM Linux when working on a distribution for Acorn computers
in the early 1990s. Now, ARM is one of the best-supported processors
under Linux and is a real joy to us. Three days was enough to port
Linux to our custom hardware, although the Ethernet driver took a couple
more days to complete. ARM is easily the world's number one processor by sales, with a
huge amount of support for running Linux. This led Tait Electronics to
commit to ARM processors in our future processor road map.

With ARM Linux booting, it was time for a RAM disk. Having 16MB of SDRAM
and 2MB of Flash memory on the ARM, we opted for a maximum compressed
kernel and RAM disk size of 1,024K each, although the uncompressed RAM disk
is 4MB in size. Both are stored in Flash and allow booting without
external interaction.

We opted to use BusyBox for common tools, including ls, cd, mount, insmod and ping,
and TinyLogin for login and password support. Other onboard
utilities handle memory-mapped peripherals and Flash, and netkit-base
provides a telnet dæmon that uses TinyLogin functions. Tait Electronics
bought a range of MAC addresses from the IEEE to support its Linux-on-ARM
development programme, and the MAC address for each board is held in
Flash memory.

Figure 2. Each unit has both a Flash-based and a RAM-based filesystem.

We developed many small applications and even got the Abyss Web server
running, but these all can't fit into Flash. We therefore NFS-mount a
directory from the zion mainframe to each ARM, accessing many gigabytes of extra
space. Figure 2 shows the filesystem arrangement.

We also set up SMB mounts to users' shared drives from zion, accessible
to the ARM boards over NFS. If a Web server is run on the ARM boards,
we end up with a highly interlinked system. Windows users can access
part of their own local drivespace through the Web served by way of an embedded
ARM board linked over NFS to a remote cluster server.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.