United Business Media EE Times


Search

HOMEMARKET INTELLIGENCE UNITFORUMSDESIGNNEW PRODUCTSCAREERSBLOGSCONTACTEVENTSSIGN UP!RSSMost Popular contentTrusted Sources

 


Multiprocessor migraines?
Print this article Email this article Reprints RSS Digital Edition

EE Times


BIER_JEFFOnce upon a time, most signal processing applications were powered by single-proces-sor chips. Today, though, there is an increasing trend to use complex, heterogeneous multiprocessor chips. One such chip is Texas Instruments' recently announced Omap 2, which contains a microprocessor core, a DSP core and multiple application-specific coprocessors.

The primary motivation for this shift is not processing speed; the fastest uniprocessor DSPs and general-purpose microprocessors are fast enough for many performance-hungry signal-processing applications. Instead, multiprocessor chips are gaining popularity because they deliver strong computational speed along with prices suitable for high-volume applications and (at least in some cases) energy efficiency suitable for battery-powered systems.

These devices, of course, are more complex. Instead of a single processor architecture and a single tool chain, users have to contend with multiple architectures and tool chains. Many chip vendors try to ease this process by providing software and middleware so that the user doesn't have to develop all of the code from scratch. Nevertheless, users will likely need to develop, optimize and debug some software for each processor on the chip.

Perhaps even more daunting is partitioning an application across different processors. Unlike "channelized" applications, which often use multiple instances of the same processor to execute the same software in parallel, applications that use heterogeneous multicore chips run different portions of the application on different processors. So which portion goes where?

Ideally, you'd like to run each block of code on the processor that's most efficient for that block. But that may not be obvious until you've actually implemented and optimized each block on each processor-which is not a viable approach. In addition, you'll have to consider the overhead associated with interprocessor communication. That may mean that certain blocks are best mapped to a less-efficient processor to avoid excessive shuttling of data.

Given the advantages of heterogeneous multiprocessor chips, system developers will put up with some added complexity. But it is up to the chip vendors to provide the needed infrastructure to help make that complexity manageable.

Jeff Bier is the general manager of Berkeley Design Technology Inc. (www.BDTI.com), the DSP technology analysis and software development company. Jennifer Eyre of BDTI contributed to this column.





The views and opinions expressed in this column are strictly those of the author and should not be taken as an editorial position of EE Times or any of its other editors, publications or Web sites.


  Free Subscription to EE Times
First Name Last Name
Company Name Title
Email address
  Click here for your Free Subscription to EETimes Europe
 
CAREER CENTER
Looking for a new job?
SEARCH JOBS
SPONSOR

RECENT JOB POSTINGS
CAREER NEWS
SRC Expands R&D Centers
The Semiconductor Research Corp has added a new center to its university R&D efforts.

For more great jobs, career related news, features and services, please visit EETimes' Career Center.


All White Papers »   

 
Education and
Learning


Learn Now:












Home | About | Editorial Calendar | Feedback | Subscriptions | Newsletter | Media Kit | Contact | Reprints|  RSS|   Digital|  Mobile
Network Websites
International
Network Features




All materials on this site Copyright © 2009 TechInsights, a Division of United Business Media LLC All rights reserved.
Privacy Statement | Terms of Service | About