This web log is the product of the collaborative, innovative, virtual minds of the editors of the IBM developerWorks Multicore acceleration (Cell/B.E. SDK) zone.

Product watch: SDK 3.1 documentation available

Version 3.1 of the SDK for Multicore Acceleration is here: With new documentation and links to the exciting new IBM Systems Information Center, a single, searchable Web place where the documentation is "live."

It came from the Lab: Don't eat so much CO2

Cell to reduce greenhouse gases via fast sims: IBM and USaskatchewan are collaborating to understand better how to limit carbon dioxide emissions from coal-fired electricity plants -- they're doing this by setting up a simulation system consisting of BladeCenter QS22 Cell/B.E. blades. USaskatchewan research lead Raymond Spiteri noted that such simulations -- including determining how the plants can be modified to harness pre-released CO2 and change it into benign by-products or other fuels like methanol -- "used to take 10 days to complete ..." because the university rented time on a system to run the results. Now the results "will now be completed in under one day ... getting results back faster enables us to be more ambitious in our simulations and try more ideas and different scenarios." Spiteri has already started working with IBM scientists to build a model for relevant chemical reactions and to craft algorithms and code for the Cell/B.E. processors.

Product watch: TotalView supports Sony's BCU-100

Adds support for the ZEGO platform: TotalView Technologies has added support for Sony's BCU-100 Cell Platform (ZEGO) to its TotalView 8.6 source code debugging, analysis, and memory-error-detection tool. The Cell/B.E.- and RSX-based BCU-100 is designed (through its multicore architecture) to improve the efficiency of workflows, especially in the area of digital video production. With TotalView 8.6's Cell/B.E. support, ZEGO users can now examine and troubleshoot digital video program execution. (For more on ZEGO, see "Sony debuts new hybrid multicore Cell/B.E. platform." For more on TotalView, see "TotalView Debugger gets Cell/B.E. support.")

Oddments: What the world will look like ...

when robots take your job: Electrical engineer Marshall Brain (also founder of How Stuff Works) thinks robots may put us out of work in the next 20 to 30 years. At the recent Singularity Summit, Brain claimed that the coming industrial revolution will probably realize the fear that the original Industrial Revolution didn't -- that a "second intelligent species" may be a disruptive technology, at least to the human economy. But he's not trying to hold back the coming tide. Brain suggests we restructure the economy before this happens to make it beneficial for all, humans and robots. For example, distribute the benefits of the revolution to every person via a US$25K-year stipend. (He's also proposed some other interesting ideas to remove "dysfunctional elements from the capitalistic system.")

when robots take your dog's job too!: GATech researcher hope to reduce the cost and availability problems in the service dog industry by designing a robot to handle those tasks. The researchers claim that there are never enough service dogs to go around, they cost about US$16K a piece, and it takes about two years to train them. Phase One of their research yielded a point-and-click laser the user can use to point out the object to be fetched. The robot dogs already respond to a range of verbal commands, so the initial prototype was built with off-the-shelf robotic parts with a custom manipulator that mimics a dog's mouth.

Cell/B.E. Security SDK: APIs: Data transfer

#include <libisolation.h>

int copyin(uint64_t ea, void *ls, uint32_t size)

#include <libisolation.h>

int copyout(uint64_t ea, void *ls, uint32_t size)

#include <libisolation.h>

int decrypt_in(void *dst_ls, const uint64_t ea, const uint32_t message_size,
     const vector unsigned char shared_key)

#include <libisolation.h>

int encrypt_out(const uint64_t ea, void *src_ls, const uint32_t
     message_size, const vector unsigned char shared_key)

Cell/B.E. Security SDK: APIs: Secure File Storage

#include <libisolation.h>

SFS_FILE *sfs_file_var;

#include <libisolation.h>

SFS_FILE *sfs_fopen(char *filename, char *mode,
     const vector unsigned char key);

#include <libisolation.h>

int sfs_fclose(SFS_FILE *stream);

#include <libisolation.h>

int sfs_fread(void *buffer, size_t element_size, size_t count,
     SFS_FILE *stream);

#include <libisolation.h>

int sfs_fwrite(void *buffer, size_t element_size, size_t count,
     SFS_FILE *stream);

#include <libisolation.h>

int sfs_fseek(SFS_FILE *stream, long int offset, int wherefrom);

#include <libisolation.h>

int sfs_ftell(SFS_FILE *stream);

Product watch: SDK version 3.1 available

Version 3.1 of the SDK for Multicore Acceleration is here: With new documentation and links to the exciting new IBM Systems Information Center, a single, searchable Web place where the documentation is "live."

It came from the Lab: Plasmon lens create denser chips

Plasmonic lithography: UC-Berkeley engineers have found a way to breathe new life into optical lithography called plasmonic lithography -- by using metal lenses that focus light by exciting electrons (plasmons), they've been able to create line patterns 80nm wide or about 10 times smaller. The resolution and defraction you can get with regular light is a limiting factor; to overcome this, they leveraged a property of metals -- the presence of free electrons at the surface that oscillate when exposed to light (evanescent waves, smaller than the wavelength of light).

Product watch: Automated debugging and Cell benchmarks

TotalView batch debugger: TotalView 8.6 (source code analysis and error detection tool) has added features: automated batch and remote access debugging. Via a new troubleshooting utility called TVScript, users get automated and unattended debugging. They can also perform multiple runs of a single version of a program without recompiling or stopping to make source edits. Another feature, the Remote Display Client, offers users the ability to set up and securely operate a remote interactive graphical debugging session.

Cell benchmarks "good" for Express Logic NetX TCP/IP Stack: A paper by Sony engineers -- "Network Processing on an SPE Core in Cell Broadband Engine" -- shows that a recent test of the company's NetX TCP/IP network stack and ThreadX RTOS achieved speeds reaching 8.5Gbps. Due to Linux's standard protocol stacks's large memory footprints (which exceed the 256KB SPE memory size), it has been difficult to drive to the maximum bandwidth of on 10Gbps Ethernet. Express Logic's protocol stack designed for embedded applications is less than 30KB which makes it fit easily into the 256KB limits of SPE local memory.

Faster than a speeding bullet: There's a supercomputer on my lap

Most laptops best 1980's fastest: TechRepublic's John Sheesley takes you on a walk down memory lane when the phrase "supercomputer" didn't conjure up images of LANL's Roadrunner* Cell/B.E.-Opteron hybrid but instead made you think Cray. He points out that the laptop many of you are using right now is faster than the 1980s version of a supercomputer like the Cray Y-MP -- up to eight 32-bit processors that ran a max 333MFLOPS for a combined sustained speed of over 2GFLOPS. It sped along at 167Mhz and could handle both 24-bit and 32-bit instructions. (Remember, the best in desktop at the time was the 32-bit 486DX/2 66 with an internal clock rate of 66Mhz.)

Sheesley's got another post on How Star Trek influenced the development of the curved tower design of the Cray supercomputers.

How do we reach 1 exaFLOPS?
Practice, practice, practice?: In International Science Grid This Week, David Anderson, founder of the popular volunteer computing site Berkeley Open Infrastructure for Network Computing (BOINC), discusses how to best the current record of 1PFLOPS (earned by distributed efforts like BOINC and Folding@home and the solitary LANL Roadrunner*). Anderson notes that simple scaling current efforts may be hampered by steep power-consumption and heat-dissipation curves; his suggestion to reach the next height is a combination of volunteer computing and using graphics processing units (GPUs). Although the specific-task-oriented nature of GPUs made reprogramming them for compute-intensive scientific applications difficult, a newer trend in GPUs is for them to be more general-purpose (even delivering up the coveted double-precision floating-point math). Anderson mentions NVIDIA's CUDA system that allows GPUs to be programmed in C and makes it easier to develop and port scientific apps to GPUs.

(*Please see the disclaimer on the use of the LANL Roadrunner name.)

Design on a dime: Multicore partitioning as a design issue

Learn how to think outside the linear execution box: Richard A. Quinnell of EE Times writes an interesting article highlighting the need to take partitioning into account when you design applications for multicore systems. He starts by providing a friendly warning that the trends show that even traditional general-purpose processors (and the products they are used in) are turning to multicore architectures. Quoting RTOS vendor Express Logic's John Carbone, Quinnell makes the point that moving software to multicore requires overcoming two obstacles:

• You have to find a way to distribute the threads.
• You have to find a way to enable "communications among the threads across processor boundaries."

Quinnell goes on to remind that the only way multicore processing is a win is if all the cores remain busy (that is, none are idle and none are overburdened) -- partitioning can be the answer to this problem (just as it can increase competition among cores for shared resources if not done correctly). Some of his basic suggestions to achieve adequate partitioning include message passing and semaphore mechanisms to help threads swap info and coordinate their actions across boundaries. Quinnell also supports simplifying the implementation of these mechanism (like with the Multicore Communications Applications Programming Interface standard effort) and tool-developers' efforts.

Users need this for on-chip mcore debugging
Mcore challenges debugging: This technical paper by Jens Braunes, software architect at pls Development Tools, details the importance of understanding user requirements before choosing an on-chip debug setup for a multicore system by providing a checklist of sorts, including

• "Must each core and bus must be observable?"
• "Is it crucial for system analysis to recognize events that arise from interactions between the cores and busses?"
• "What level of complexity (in interactions between all SoC components) during debug is needed?"

Braunes covers four sets of signals for basic multicore debug capabilities (debug control, JTAG interface, debugger interface, and cross-trigger interface), how you may want to build specific debug functionality into the design (based on customer needs), how using the multicore debug solution (MCDS; configurable IP building blocks) helps measure performance indicators, and more.

Trends and tradeoffs: Slippery interconnect requirements for multicore

Are standards-based interconnects ready for the transition: Freescale systems architect Greg Shippen wonders if existing standards-based interconnects are ready for the transition that multicore SoC devices are beginning to trust on developers and designers -- namely, the rearrangement of boundaries among silicon devices, boards, and subsystems. Board and system-level interconnects were originally based on the shared bus; the demand for better interconnect performance was realized through an increase in the clock rate and a widening of bus widths, but physics put a stop to that. Shippen lays out a direction (including new protocol features to provide de-multiplexing services at the destination point) to make it possible for current interconnects to support multiple traffic streams.

Product watch: Matrix Vision and MatLab

MatLab goes parallel: In a new release of the MatLab environment, MathWorks introduces parallel programming capabilities. MatLab 2008b allows users to distribute parallel MatLab applications as standalone executables or software components, making it easier to leverage clusters and multicore systems. This feature is a new language construct in MatLab's Parallel Computing Toolbox 4.0; it lets you mix serial programs with parallel ones using the familiar single program, multiple data construct (also known as spmd) used by parallel programmers in technical apps for clusters.

Video application/hardware solutions: Matrix Vision offers a host of products to help you with digital image processing on your Cell/B.E. system, including the mvHYPERION-16R16 and 32R16 frame grabbers (which acquires 16 video channels in real-time via PCIe x4 and are optimized for Cell/B.E. processors) and the newest, the CameraLink frame grabber mvHYPERION-CLf/Cell for FULL CL cameras, optimized for applications in high-end machine vision solutions.

Oddments: BANs, qencryption, local power, and fake flowers

Again with the wearable network!
Low-power DSP: IMEC researchers are planning a custom ultra-low power digital signal processor to be used in a wireless sensor node that will most likely be the centerpiece of a body-area network. Plans are for the node to consumer 100microwatts or less. An off-the-shelf prototype used an algorithm running on a PC to determine an overall level of excitement based on readings of heart rate, skin conductance, temperature, and breathing rate.

Quantum encryption: Awesome and pointless
Famed security expert Bruce Schneier weighs in: Security expert Bruce Schneier thinks quantum cryptography is a very cool idea -- and that it is probably almost completely useless in real-world application. Schneier doesn't believe it solves any problem that needs solving because the quantum part doesn't address the real weaknesses in the system (in his words, "Systems that use it don't magically become unbreakable"). Schneier notes that his opinion comes about because he sees security as a chain, only as strong as its weakest link -- mathematical cryptography (which qencryption would replace) is already the strongest point in the chain. So qencryption would still be subject to the effect of the other weak links. As always, Schneier makes you think. (See "Tap this you eavesdroppers! Qencryption prepares to ravage small blue planet" for more on qencryption.)

Blender operates without wires
Plop it on the power pad: Fulton Innovation has linked its eCoupled technology with a kitchen blender, producing a blender without a power cord. You simply plop it on eCoupled-enabled countertop. So for those of you who hate power cords, here's your chance.

And speaking of power ...
Thomas Jefferson's idea on local generation gets new life: VATech researchers are resurrecting Thomas Edison's concept of local power generation to minimize blackouts at the local level. They're planning a network of privately-owned microgrids that use renewable energy sources in order to test two issues -- how resilient and how sustainable interdependent electric power and communications systems can be. On the resilience side, they will be examining how well microgrids can manage risk of cascading failures (that lead to the big blackouts); on the sustainability side, they'll determine how easy it is to make the system agile enough to respond to changing conditions and environmental challenges.

Smells like a real flower
Droid plants do the same thing as real ones, but they're robots: ChonnamNatU's robot lab has gotten a pseudo-green thumb -- it's building a robotic plant that humidifies, produces oxygen, emits aromas, and responds to stimuli (like bending towards light, music, or approaching people -- Triffids?!?). It looks like a Rose of Sharon and early indications are it doesn't need watering. In fact, you need a power surge to kill it.

Cell/B.E. Security SDK: Building apps: Introduction