March 2006 87

I recently read Thomas L. Fried-man’s book, The World Is Flat: A Brief History of the Twenty-first Century (Farrar, Straus andGiroux, 2005). Focused on eco-

nomics, the book also includes inter-esting observations about the infor-mation technology revolution.

Friedman observes, for example,that data communications on portableand handheld devices will mark thebeginning of the IT revolution. Thefoundation of this revolution, in addi-tion to Internet and wireless commu-nications, will be portable and hand-held computing devices that will re-place desktops, laptops, and cellphones, ultimately morphing intosomething entirely new. At the heart ofthese devices, single-chip computerswill provide and integrate a diverse setof applications that use entirely newarchitectural, design, modeling, simu-lation, and evaluation techniques.

If these are to be considered embed-ded systems, we must find a definitionfor embedded other than “something acomputer architect is not interested in.”

Many people still think of embed-ded systems as computers interactingwith noncomputer, physical systemssuch as automobiles and power plants.Yet the next-generation computers at

the foundation of portable and hand-held computing are no more embed-ded systems than they are single-threaded systems, and they are cer-tainly not servers or other conven-tional parallel processors. We mustdetermine the impetus and audiencefor researching these next-generationcomputers.

Friedman’s book points out thatdeveloping nations, with no previousinfrastructure, are often more adept atadopting newer technologies thannations encumbered by such an infra-structure. Research also has this char-acteristic.

I have been trying to find a way towork on the fundamental problems ofnext-generation computer design forthe past several years—problems thatchallenge the conventional wisdom ofthe CAD community, with its deeproots in formal modeling and synthe-sis, and the computer architecture com-munity, which seems willing to sacrificeanything but existing programmingmodels. Identifying an interesting prob-lem to work on, it turns out, can bemore of a curse than a blessing.

I can best explain this by includingsome personal observations. Myresearch community has been definedas “System-Level CAD,” “Embedded

Systems,” and “Codesign,” withseemingly no end to the new monikersthat embrace all and convey little.Revisiting the name game in this com-munity provides a good starting pointfor considering other problems.

A research community’s signatureconference defines it, for both practi-cal and idealistic reasons. The practicalreasons pertain to the reward structurefor doing research. For both academicsand those who still do research inindustry, dollars, publications, andreputation measure productivity.

It isn’t possible to evaluate goodideas, good works, and good peoplejust by reading proposals or journalpapers. At a good conference, coffeebreaks—which result in informal con-versations—can be as important as thepresentation rooms. This is whereresearchers have an opportunity todistill and clarify their ideas—forthemselves and for their audience.That audience could be a potentialindustrial partner, a future paperreviewer, or someone who might writea letter supporting anything from apromotion to a career-long award.

In a more idealistic sense, confer-ences offer the only forum that pro-vides a shared identity and a true peergroup experience for an otherwise dis-tributed group of people who have acommon, logical research focus. Aswith other kinds of peer groups,research groups provide a personalreason to continue doing good workslong after a researcher has establisheda reputation: People do such worksbecause they gain satisfaction fromknowing that their peers appreciatetheir contribution.

CODES+ISSSCODES+ISSS is the conference that

I, as a researcher, identify with mostclosely. The 2005 conference providedanother opportunity for my researchcommunity to establish a new namefor the work it does. This is a source ofintrigue, because the conference con-tinues growing in popularity eventhough its name derives from tworesearch areas that no longer describethe work it embodies:

What’s in a NameJoAnn M. Paul, Virginia Tech

E M B E D D E D C O M P U T I N G

Named research areas attract faculty, students, and funding;unnamed ones don’t.

88 Computer

Unfortunately, the implications ofpursuing a research area that lacks adescriptive name are huge:

• Students apply for graduate posi-tions to work in named areas.

• Faculty advertisements are oftenrestricted to hiring those who workin named areas.

• Funding agencies, such as theNational Science Foundation andthe Semiconductor ResearchCorporation, solicit proposals forresearch done in named areas.

• In academia, contributions areevaluated by peers—researcherswho pursue common interests. Ifthe common interests cannot benamed, contributions becomemore difficult to evaluate.

• If its objectives cannot be named,the research community has diffi-culty attracting new people inter-ested in solving new, fresh, andexciting problems.

If I tell those outside the CODES+ISSS community that my research is in ESL design, they have no idea whatI do. By contrast, those who work innetworking, reconfigurable computing,computer architecture, computer secu-rity, or even artificial intelligence canquickly establish a first-order approxi-mation of the work they do in one ortwo words. With these descriptivenames, they categorize themselves bythe area of expertise they bring to thetable.

SYSTEM FRUSTRATIONSThis experience forced me to con-

sider why the CODES+ISSS commu-nity is simultaneously so interestingand frustrating.

Again, this can be seen more clearlyby considering what’s in a name.Consider the heavy reliance within the

• CODES was the name of the Inter-national Conference on Hardware/Software Codesign, while

• ISSS was the name of the Inter-national Symposium on SystemSynthesis.

The older of the two, ISSS, was estab-lished as a place to publish work onbehavioral—or system-level—synthesis.In those days, system synthesis meantcomputer hardware synthesis—synthe-sizing an application-specific integratedcircuit from hardware description lan-guages such as Verilog or VHDL.

ASICs offer performance advan-tages at the expense of post-design-time programmability. This contrastswith computer architecture, whichfocuses on support for a wide varietyof end-use programming scenarios.

Hardware/software codesign grewout of system-level synthesis. Whenprocessors, and thus software, startedto appear on single-chip computersthat were previously designed only inhardware, a question emerged in thesynthesis community: What should goin hardware and what in software?CODES addressed this partitioningproblem for several years.

Currently neither hardware synthe-sis nor hardware/software codesigndescribe the system-level design rep-resented in CODES+ISSS. Mostdesign problems in CODES+ISSSassume the need for more than onepiece of hardware and typically evenmore than one kind of processor.

Still, when the new CODES+ISSSconference formed, the founderscould not agree on a new name. Thewords system and embedded keptappearing in various proposals. Theseare the least offensive words preciselybecause they say so little.

Without agreement, the old name,CODES+ISSS has remained. Thename is more a moniker about peopleand their legacy than about researchobjectives and the future. During the2005 conference, some speakers intro-duced a new name: Electronic SystemLevel (ESL), which suggests researchthat requires no particular kind ofexpertise or skill.

CODES+ISSS community on the useof the word system.

System design tends to bring tomind the pulling together of diverse,interacting elements to create some-thing entirely new. The need for whatthe system does drives the process ofcreating it. In the case of computersystems, the need is the application. Asystem is defined more by what it doesthan what it is.

For this reason, those working inESL design always search for the nexthot application, be it network pro-cessing, multimedia, or sensor arrays.Notice the contrast to computer archi-tecture, where existing benchmarksuites define the evaluation space.

Computer system design is applica-tion-driven, and therein lies a prob-lem. World-class researchers will morelikely earn their reputation by focus-ing on what something is and gener-alizing what it can and cannot be.Those who choose to define them-selves by pursuing an ever-expandingcollection of interesting design situa-tions are more likely to becomeknown for being high-tech handymen:engineers in search of solutions ratherthan researchers in search of truths.

At the same time, however, beingmotivated by applications presents anopportunity. Communities flexibleenough to chase the next hot applica-tion are well-poised to occupy theleading edge.

How then does a researcher inter-ested in developing the fundamentalwork necessary for next-generation ITdevices gain a reputation as a world-class researcher?

CORE FOCUSIn contrast to CODES+ISSS, other

research communities focus on inves-tigating and extending a core set oftechniques and organizing principles.These researchers have a specificexpertise in a specific discipline, andthey bring that expertise to bear on acore set of problems. At the sametime, they seek to provide the foun-dation for generating somethingnew—and that something new will inturn enable new applications to exe-

E M B E D D E D C O M P U T I N G

The words system andembedded are the least

offensive choices preciselybecause they say so little.

cute more quickly, occupy a smallerspace, function more robustly, or pro-vide greater scalability.

Given the challenges that next-gen-eration single-chip computing poses,our field is not unlike computer archi-tecture in the days before formaldesign resulted in the definition offinite state and Turing machines,before Amdahl’s law, and well beforethe establishment of a common bench-mark set and simulation platform.Back then, researchers seemed toknow they needed a common basis fordiscussion more clearly than we dohere on the IT revolution’s frontier. Aswell, back then there was much lesslegacy work to build upon.

Somewhere between the inertia builtup in computer architecture and thelack of focus in the CODES+ISSS orESL community, lie both the need andthe opportunity to provide fundamen-tal research for a new class of comput-ing problems. There is a fundamentalset of interesting research problems outthere, but no real forum to get the atten-tion of research sponsors to define thoseproblems nor for young researchers tobe accepted for working on them.

I believe the best opportunity existswithin the CODES+ISSS community,if that community will trade some ofits flexibility for focus.

V irtually all the work representedin CODES+ISSS is either aboutsystems that use multiple, het-

erogeneous design cores, or about thedesign of elements to be used in thosesystems.

I propose a new research commu-nity defined around the design of het-erogeneous core computers. TheseHCCs will emphasize the creation andintegration of multiple design coresand the programmable nature of theresulting computer. The result will bea community focused on integrationas well as architecture, design as wellas programming, and evaluation tech-niques as well as design tools.

Heterogeneity distinguishes portableand handheld computing from othersingle-chip multicore communities. It

arises naturally from the need to placea set of applications upon a finiteamount of space such as a chip. Giventhat the chip has finite real estate,homogeneity is wasteful. Further, weknow enough about the applicationsat design time to favor differentiatingportions of the chip at a fairly highlevel, well above the register level.

With this or even some other focus,our community can attract the bestand the brightest. Who among themwill be first to gain recognition fortackling the following fundamentalquestions:

• What are the design elements ofHCCs?

• What is the HCC programmingmodel?

• How many kinds of heterogeneouscores do we really need?

• How sensitive is overall HCC per-formance to a single core’s perfor-mance difference?

• How do we schedule across multi-ple, heterogeneous cores?

• When is having the same task exe-cute on multiple cores worthwhile?

• When and how is global coordi-nation useful and when is it waste-ful?

• Many HCCs will be multimodal;how does utilization factor into thebenefits of specialization?

• When does using multiple coresand incurring their coordinationcost work better than using a sin-gle, faster core that multiplexesmany tasks?

These questions should be posed,pursued, and answered as part of abody of work a clearly identifiableresearch community performs, wherepeers can reward and evaluate funda-mental works. Thus, we can take a bigstep toward providing a set of enablingsolutions for the IT revolution by firstredefining our community. ■

JoAnn M. Paul is an associate professor inthe Electrical & Computer EngineeringDepartment at Virginia Tech. Contact herat jmpaul@vt.edu.

March 2006 89

Editor: Wayne Wolf, Dept. of Electrical Engineering, Princeton University, Princeton NJ; wolf@princeton.edu

Learn how others are achieving systems and networks design anddevelopment that are dependable and secure to the desireddegree, without compromising performance.

This new journal provides original results in research, design, anddevelopment of dependable, secure computing methodologies,strategies, and systems including:

• Architecture for secure systems• Intrusion detection and error tolerance• Firewall and network technologies• Modeling and prediction• Emerging technologies

Publishing quarterlyMember rate: $31Institutional rate: $285

Learn more about this newpublication and become a subscriber today.

www.computer.org/tdsc

IEEE TRANSACTIONS ON DEPENDABLEAND SECURE COMPUTING