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 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.
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.
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.
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
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.
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!
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.
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.
The downloads for this article are being updated. Please try to download later.
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
- Participate in the discussion forum.
- Got a question on how to leverage and program
the processor? Pose your question in the
Cell Broadband Engine Architecture forum.
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.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
