Level: Intermediate Lewin Edwards (sysadm@zws.com), Design Engineer, Freelance
15 May 2007 How do you take the Cell Broadband Engine™ (Cell/B.E.) processor from an
off-the-shelf Sony® PLAYSTATION® 3 (PS3) and use it to construct a piece of
Linux®-based laboratory equipment (in essence, taking the Cell/B.E. from fab to hab
to lab)? In this series, Lewin Edwards shows you how to go from game console to
simple audio-bandwidth spectrum analyzer and function generator. First up, uncover
the design intent of the project and then make a close inspection of the details of
the user interface implementation as you start a journey to generate and analyze
signals on the Cell/B.E. processor.
The Cell Broadband Engine (Cell/B.E.) processor has attracted a lot of
fashionable attention for applications involving game playing and network data
processing. However, there are many other, arguably more entertaining uses for
this technology.
In this series of articles I will be using a Cell/B.E. processor — resident within an
off-the-shelf PLAYSTATION 3 (PS3) — to build a Linux-hosted piece of laboratory
equipment, namely a simple audio-bandwidth spectrum analyzer and function
generator.
In this first article, I'll describe the design intent of the project and go into
details of the user interface implementation.
The setup
The specific hardware and software combination I'm using is a 60GB PS3 running
Yellow Dog Linux 5.0 (YDL). I am using a standard NTSC television set as my output
device and I also added a vanilla USB keyboard and mouse and a Griffin iMic to the
system (more on that peripheral later).
Everything I am doing here should be compatible with both the 20GB version of
the PS3 and almost any other compatible Linux distribution (the only other distro
known to work at the time of writing is Fedora Core 5 for PowerPC®). The reason I
chose YDL is purely because it offers the path of least resistance — Terra Soft
has assembled and certified it for use on the PS3, and it includes
everything you'll need to get up and running with the development process and the
hardware we intend to use.
If you're more comfortable with a different PowerPC Linux distribution, then
feel free to use it — but you might need to download some additional components
not mentioned explicitly in this text. Similarly, I chose the iMic because it is
known to be well-supported by PowerPC Linux — again, you're free to use any USB
audio input device you wish, but locating drivers is left as an exercise for the
reader. As a sidebar, note that you do not need to buy a PS3 game controller; you
can control the Sony operating system with a USB keyboard (at least enough to get
Linux installed, after which you'll never need to interact with GameOS again).
Please refer to the Resources section for links to the
products mentioned. If you plan to follow along and build and test the example
code, you should also begin by reading and following the instructions in Jonathan
Bartlett's article describing how to install Linux on the PS3 (see Resources). This
is a relatively well-documented and fairly simple Linux install compared to some I
could name, but it's not quite as simple as just inserting a DVD and clicking
"Go." Some hand-holding is definitely necessary.
If you don't want to invest in a PS3, you can build most of the code inside the
Cell simulator, but there probably isn't a lot of point unless you're also willing
to write a front end to simulate the audio input/output devices (perhaps using
.WAV files) and graphical display.
The rationale
Now, you might ask: What is the rationale behind using Cell/B.E. processors in
an application of this type? More often than not these days, engineers need to be
able to control test equipment from a PC and get all test data acquired back into
the computer to be imported into analysis software such as Mathcad or Matlab.
Given the increasing complexity and PC-centric nature of instrumentation, a
general trend for practically all modern standalone laboratory instruments is that
they are based around embedded PCs with some custom magic bolted onto the front
end.
For example, a digital oscilloscope might contain a fairly low-end processor
running a general-purpose operating system -- this processor will handle the user
interface, networking, mass-storage and so forth. One or more digital signal
processors (DSPs) coupled to fast analog-digital converters (ADCs) perform the
signal acquisition and pre-processing, trigger generation, and so forth.
Functionality in a single package
With a Cell/B.E. processor, you can wrap most of that functionality up into a
single chip -- in the base architecture, you already have a frisky main processor
(the PPE) and eight DSP-like coprocessors (the SPEs). Moreover, the chip includes
all the necessary plumbing to move bite-size chunks of DMA data around without any
additional hardware design effort on your part.
The broad intent is that the software developer should use the PPE to herd data
blocks from input streams to the SPEs, where the real computational magic takes
place, and thence back to the output devices.
The tools are still familiar
Once you get your software development team over the surprisingly gentle
learning curve of understanding the SPE programming interface, you can develop the
whole system using familiar tools. You therefore end up with a laboratory
instrument whose characteristics are defined almost entirely by software without
any need to get involved with special-purpose DSP toolchains, tricky DMA
architectures, ASICs, or FPGA programming.
Slight degree of customization
Note that while a from-scratch Cell/B.E. hardware design is
definitely nontrivial, the degree of hardware customization required to develop a
special application from a working Cell/B.E. reference design is comparatively
small (since much of the device's important attributes can be implemented in
software). Buried in this fact is the implication that significant functionality
upgrades can be sold to end-users as simple software updates without any need to
develop and certify new hardware.
This seems to be a compelling set of advantages and I would not be surprised to
see Cell/B.E.-based spectrum analyzers, waveform synthesizers, and other complex
test equipment such as base station simulators appearing in the near future.
The example
In this specific example, I'll start by looking at few things you need to know:
- Where's the Linux?
- Keeping the box from going up in flames.
- Working with the display
- Text-rendering code
Finding our inner Linux
When building an application around a PS3, you are constrained quite severely by
the PS3's hardware and software design -- in particular, the fact that Sony has
sandboxed Linux away from much of the hardware. A fully custom design — or even
simply a generic Cell/B.E.-based mainboard with a custom PCI Express card
containing your data acquisition/output hardware — would be much more flexible.
However, in line with the modest capabilities of the iMic, our target for this
series is to work with two parallel (stereo) 44.1kHz 16-bit data streams, implying
an audio bandwidth of 22.05kHz.
Ouch! That's hot!
Before you start, an important note: The PS3 hardware was designed to sit on a
TV set or entertainment center, not on a workbench. It generates a lot of heat
which is extracted by a fan that blows out the end of the unit closer to the
Blu-Ray drive, as well as out the back.
When I first unpacked the unit, I ran it on my workbench next to my laptop with
the PS3's fan blowing into the laptop's exhaust vents — the laptop eventually
went into thermal shutdown. So I advise you to run the PS3 "standing up" (so the
PLAYSTATION 3 text is right-side up; there are feet on the bottom of the unit to
assist with this). In this configuration, it seems to run the coolest.
A picture's worth a thousand code lines
With that out of the way and Linux installed, the first task you need to tackle
is working with the display. The default display configuration for your PS3's
Linux install will depend on how exactly you installed it. If you're running with
a normal NTSC or PAL TV set (as opposed to HDTV or a VGA converter connected to a
monitor), it's not possible to use YDL's graphical install mode because it tries
to set one of the progressive scan resolutions.
Therefore, the default Linux install will come up without X and with a
TV-resolution screen. You can alter this behavior by editing /etc/kboot.conf —
for the purposes of this article series, you'll want to run in one of the RGB
modes, either 480i for NTSC users or 576i for PAL/SECAM users. Either of these
will give you a screen size reported as 576x384 pixels by the framebuffer device;
more on that a little later.
The specific framebuffer video mode at boot time is set by parameters passed to
the kernel by the bootloader, kboot. (Note that this video mode setting is only
examined after the ps3fb framebuffer device loads, since it is a kernel parameter.
The video mode between the moment you power on and the moment the ps3fb device
initializes is whatever you set in the Sony GameOS menus; by default, it's the
interlaced SDTV resolution for the locale where your PS3 was purchased). The
settings for kboot are stored in /etc/kboot.conf — here's how I've configured my
system. Most of this is taken directly from the configuration generated by the YDL
installer; I simply changed the video mode:
default=ydl
timeout=10
root=/dev/sda1
ydl='/dev/sda1:/vmlinux-2.6.16-20061110.ydl.2ps3
initrd=/dev/sda1:/initrd-2.6.16-20061110.ydl.2ps3.img root=/dev/sda3
init=/sbin/init video=ps3fb:mode:33 rhgb'
|
Changes made to kboot.conf take effect immediately from the next reboot; you
don't need to do anything special to propagate the new configuration into the
bootloader.
If you're using a TV set and you're in Europe, you will probably want to run in
mode 38; simply change mode:33 to
mode:38 in the previous listing. As a matter of
interest, you can view a complete list of available modes by using the
ps3videomode -h command. You can experiment with
different modes on the fly by running
ps3videomode -v <number>.
Now we'll do whatever it takes to write some pixels to that fresh new slate of
blank video memory.
The PS3 video subsystem is heavily firewalled away from Linux by the Sony GameOS
"hypervisor." It is not clear how much of this is due to a generalized terror that
someone, somewhere may someday copy a PS3 game or see an unencrypted byte of HD
video content, or how much is simply because Sony needed to develop a method of
exposing a video interface to Linux without releasing any register-level
documentation on the GPU (observe that this would potentially bring in all kinds
of GPL side effects such as requiring public disclosure of code that is covered by
a nondisclosure agreement with nVidia).
Whatever the motivations, the ps3fb video device works a little differently from
other Linux framebuffers, which is both a curse and a blessing. An excellent,
quite detailed Sony document on how it works is provided in the Resources section,
although it neglects to mention at least one irritating bug. The points you need
to observe can be summarized succinctly:
- Normally, framebuffer devices give you direct access to the video card's
memory.
- Using the ps3fb device, your application writes to a main-memory (offscreen)
buffer. Every vertical blank, the hypervisor DMAs this buffer to the GPU memory,
and then flips the GPU's visible page to the new data synchronously with the
vertical blank signal.
- The advantage to this system is that you never need to worry about "tearing"
effects in animations caused by updating the screen contents partway through a
frame.
- ps3fb also exposes ioctls that permit you to run the screen in a sort of
single-buffered mode where you stop the periodic interrupts and explicitly dump
new video data to the GPU when your application feels it's appropriate (still
through the hypervisor, of course). X uses this mode.
The irritating bug to which I referred is that the standard mode-info query
ioctls don't quite work properly, at least for television resolutions. As I
mentioned early on, the NTSC and PAL resolutions both report a virtual/physical
size of 576x384 pixels. This isn't even vaguely correct; the actual width of the
NTSC screen is 720 pixels and the height (as determined by mapping and poking
progressively larger slices of RAM) is actually something like 480 lines, though
the framebuffer console seems to stop at about 400 lines and the 480th line is
somewhere off the bottom of the screen in the overscan area, at least with the
default video configuration.
Therefore, generic framebuffer code that doesn't explicitly understand the PS3
will break spectacularly if you simply compile it and let it run. My workaround is
to coerce the code into believing it's running on a 720x400-pixel screen, which
seems to work nicely. You will want to change this if you're using something other
than an NTSC TV set as your output device; though the code will still operate, it
probably won't generate a legible display.
Another definite oddity of the PS3's output is that the overscan color is
whatever was being output in the last pixel of the previous scanline. My theory on
this is that the RAMDAC has a pixel latched into it on each DMA cycle and this
latch freezes when the raster moves outside the framebuffer area up until the
vertical blank interval, where it gets reloaded with a black pixel value. Another
possibility is that this phenomenon is caused by some kind of subtle race
condition with the hypervisor software.
The only reason I mention this is that if you draw a rectangle that touches the
left edge of the screen, you'll see that the rectangle's color extends into the
overscan area except in the upper-left corner of the rectangle (since that corner
inherited the color from the end of the previous scanline). The phenomenon is
easily noticeable even on a low-resolution television set; I don't want you
reporting this as a bug in my code, because it isn't!
Make it legible
Another feature you'll need for your instrument is text-rendering code.
Rather than draw out a character generator structure by hand, I've borrowed
font_acorn_8x8.c from the Linux kernel (this is part of the framebuffer driver
tree). Note: This is legal only because the sample code I'm providing here is
GPL-licensed. If you need a character set that will allow you closed-source
distribution, you'll need to search a bit. Red Hat's eCos operating system, for
example, includes a character set you can use. The advantage of the Linux font is
that it already includes all the hi-ASCII characters you might want.
At this point you can take a look at the sample code which includes the
initialization I described earlier, as well as functions to plot single pixels,
draw filled rectangles, and render text. The demo code in main.c draws a few
colorbars onscreen, as well as a few lines of multicolor text, and prints some
potentially interesting debugging information to the console. You'll find that all
the graphics primitives I described above are in graphics.c and graphics.h, and
are
more or less self-documented.
A keyboard caveat
One final note which comes into focus when you run the sample code: I suggest
you do not use a keyboard attached to the PS3 for your editing; do your
development over ssh (the YDL install includes a fully-functioning ssh daemon by
default; you don't need to configure anything). That way you can run the
application on the ssh console and see useful debugging info on stdout without
disturbing the graphics being displayed on the PS3's framebuffer.
Surprise! A functional
graphics interface
If you've been following along, you now have a functional graphics interface
running on the PPE with some useful groundwork primitives ready to use in more
advanced projects.
In the next article, I'll describe how to use the iMic to gather an analog data
stream, and I'll show you how to use one of the SPEs to turn the system into a useful spectrum
analyzer.
Downloads
The downloads for this article are being updated. Please try to download later.
Resources Learn
- Jonathan Bartlett's
"Programming high-performance applications on the Cell/B.E. processor"
(developerWorks, January 2007) article on installing Linux on the PS3 is essential
preliminary reading.
- Sony has released a very good document
describing, inter alia,
how the ps3fb device interacts with the GPU and your Linux programs.
Note that this is a mirror; there doesn't appear to be an official copy of this
document on Sony's sites.
- Some (very!) old information on using Linux
framebuffer devices is available at the
Linux Documentation Project.
Frankly, you're much better off looking at some sample code snippets, linux/fb.h,
for information on the various data structions, and the code and comments in the
ps3fb.c driver (drivers/video/ps3fb.c in the linux-2.6.16-20061110 tree provided
by Terra Soft Solutions).
- The developerWorks
Cell Broadband Engine Resource Center
provides new documentation, downloads, and community news for all things Cell/B.E.
- News, news, and more news can be found in the
Thursday roundups of the
Power Architecture blog.
Get products and technologies
- The
Griffin iMic is our
audio input device of choice. Note that the Web site shows a (newer) white model
of the product. The model I have tested with PPC Linux is the older,
translucent-and-silver version with a switch between the input and output jacks.
- You can get Yellow Dog
Linux through
free download from Terra Soft Solutions.
My experience is that all the mirrors are quite slow; I got the install ISO much
faster by searching a P2P network for the filename
yellowdog-5.0-phoenix-20061208-PS3.iso.
- You can download the
Cell/B.E. SDK (latest version 2.1)
from alphaWorks.
Discuss
About the author  | | | Lewin A.R.W. Edwards works for a Fortune 50 company as a wireless security/fire safety device design engineer. Prior to that, he spent five years
developing x86, ARM and PA-RISC-based networked multimedia appliances at
Digi-Frame Inc. He has extensive experience in encryption and security
software and is the author of two books on embedded systems development. |
Rate this page
| 
