106 Computer

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

I n computer technology, namesoften change. Even the word“computer” previously referredto a human whose job was tocrunch numbers, but today refers

to a machine. The advent of field-pro-grammable gate arrays requires thatwe stop calling circuits “hardware”and, more generally, that we broadenour concept of what constitutes “soft-ware.” Doing so will help establish acadre of engineers capable of maxi-mally exploiting modern computingplatforms that involve multiproces-sors and FPGAs.

When the term software was coinedin the late 1950s to raise awareness thatwriting programs was becoming asimportant as the design and mainte-nance of the hardware that then dom-inated computing efforts, the meaningsof software and hardware were clear.Hardware referred to physical compo-nents like boards, fans, tubes, transis-tors, and connections—and could betouched. Software referred to the bitsrepresenting a programmable proces-sor’s program. During the decades thatfollowed, building programs (software

design) evolved to require dramaticallydifferent skills than connecting physi-cal components into circuits (hardwaredesign).

IMPLEMENTING CIRCUITSToday, embedded-system designers

frequently supplement microproces-sors with custom digital circuits, oftencalled coprocessors or accelerators, tomeet performance demands. A circuitis simply a connection of components,perhaps low-level components likelogic gates, or higher-level componentslike controllers, arithmetic logic units,encoding engines, or even processors.

FPGAs as softwareIncreasingly, designers implement

those circuits on an FPGA, a prefab-ricated chip that they can configure to implement a particular circuitmerely by downloading a particularsequence of bits. Therefore, a circuitimplemented on an FPGA is literallysoftware.

The key to an FPGA’s ability toimplement a circuit as software is thatan N-address-input memory can

implement any N-input combinationalcircuit. For example, given the func-tion A�B�C� + ABC, it’s possible to sim-ply connect A, B, and C to the addressinputs of a three-address-input (eight-word) memory, store a 1 into the firstand last memory words, and store 0sinto the other six words. The memorywill then output 1 when ABC = 000(A�B�C� ) or when ABC = 111 (ABC),and will output 0 for any other valuesof ABC.

An FPGA has thousands of smallmemories each having perhaps fourinputs and two outputs, and eachknown as a lookup table. A circuitwith more than four inputs can bepartitioned into four-input subcir-cuits, each mapped to a LUT. To sup-port sequential circuits, LUT outputsfeed into flip-flops, collectively knownas a configurable logic block. A mul-tiplexor, along with a programmableregister that controls the multiplexor’sselect lines, chooses whether the CLBoutput comes directly from the LUTor from the flip-flop.

Finally, CLBs are preconnectedthrough miniature crossbar-likeswitches, in which programmableregisters also determine the actualpaths, to ultimately achieve a partic-ular circuit’s connections. A devel-oper thus can implement a desiredcircuit on an FPGA by writing theproper bits to each LUT and pro-grammable register, as determinedby design automation tools.

The fact that developers can imple-ment circuits as software on FPGAs isa very big deal because circuits canimplement some computations hun-dreds or even thousands of timesfaster than microprocessors. Thespeedups come from a circuit’s con-currency at the bit level, arithmeticlevel, or even process level, becauseevery circuit component executessimultaneously. For example, revers-ing the bits of a 32-bit number, per-forming 50 independent multiplica-tions, or executing 20 processes eachrequires a long sequence of instruc-tions on a microprocessor. But on anFPGA, the bit reversal is just crossedconnections, the multiplications could

It’s Time to StopCalling Circuits“Hardware”Frank Vahid, University of California, Riverside

Expanding the software concept

to spatial models like circuits will

facilitate programming next-

generation embedded systems.

September 2007 107

components or by creating a newphysical chip—things they couldtouch.

Yet today, even with circuits in-creasingly implemented as softwareon an FPGA, circuit designers are stillknown within companies as hard-ware people, circuit-design languagesare still called hardware descriptionlanguages, algorithms ported to cir-cuits are still known as hardwarealgorithms, and coprocessing circuitsare still known as the hardware inhardware/software systems. But withthe FPGA market generating billionsin annual revenue from the sale ofhundreds of millions of devices tothousands of customers, the catego-rizing of circuits as hardware isgrossly inaccurate.

EFFECT ON COMPUTING FIELDThat circuits on FPGAs are actually

software rather than hardware isn’tjust an insignificant technicality, likea tomato actually being a fruit ratherthan a vegetable. On the contrary,treating circuits as hardware hurts thecomputing field, especially embeddedsystems. The reason is that most com-puting-oriented engineers—softwaredesigners—aren’t interested in learn-ing about hardware design. Hardwareto them is a different beast. Thinkingthat circuits are hardware, comput-ing-oriented engineers aren’t moti-vated to learn to design for FPGAs,

execute concurrently on 50 multipli-ers, and the processes could executein parallel as 20 different circuits.

Underutilizing FPGAsComputationally intensive applica-

tions involving video or audio pro-cessing, compression, encryption,real-time control, or myriad othertasks found in domains like consumerelectronics, communications, net-working, industrial automation, auto-motive electronics, medical devices,office equipment, and much morecould thus execute hundreds or eventhousands of times faster as circuitson FPGAs than as instructions onmicroprocessors—without the rigid-ity, high cost, and long turnaroundtimes associated with building newchips. Such speedups, achieved usingthe changeable medium of software(on FPGAs), enable new applicationsnot otherwise possible.

Yet, embedded-system applicationdesigners working with softwareoften overlook FPGAs, even whenFPGA performance gains wouldtremendously benefit an applicationwhile satisfying cost and power con-straints. And designers never evenconceive many applications thatFPGA performance would enablebecause they don’t consider that soft-ware can meet those applications’performance demands. However,because an embedded-system de-signer faces the challenge of makingdesign tradeoffs under multipleexcruciating constraints on designmetrics like performance, power,cost, size, and design time, the effec-tive designer can’t be strong with justmicroprocessors or FPGAs; thesedesigners must be capable of findingjust the right balance of both.

Part of the problem is that comput-ing-oriented application designerstend to be unfamiliar with FPGAs,which in turn occurs largely becausethe engineering design and educationcommunities continue to treat circuitsas hardware. Until the advent ofFPGAs, treating circuits as hardwaremade sense. Designers implementedcircuits either by connecting physical

and perhaps even more significantly,computing-oriented college studentsoften avoid courses that involve cir-cuits and FPGAs, due to not being“hardware types.”

Temporal versus spatial modeling

A typical computer science depart-ment will have computing-orientedstudents with programming special-izations in graphics, the Web, or real-time system development, forexample. But rarely do computer science students specialize in FPGAdevelopment; those students are typ-ically in electrical engineering depart-ments, where “hardware” is thefocus.

The issue actually extends wellbeyond circuits and hardware andinto the realm of broadening the con-cept of computation models to con-sider both temporally and spatiallyoriented models, a concept illustratedin Figure 1. Developing modern em-bedded software capable of executingon multiprocessor and FPGA plat-forms requires expertise not just intemporally oriented modeling (Wcomes after X) like writing sequentialcode but also in spatially orientedmodeling (Y connects with Z) like cre-ating circuits.

The former involves ordering tasksin time, while in the latter, tasks exe-cute concurrently in a parallel or

Figure 1. Circuits as software.Temporally and spatially oriented computing models can

both be compiled to software that is downloaded into hardware components.

Spatially orientedcompute models

Temporally orientedcompute models

*A = 15;if (B < 20) C = A + 1;

Data-flowgraphs

CircuitsCommunicatingprocesses

Sequentialinstructions

Statemachines

Software – 0s and 1s

0100 1110 11110101 0001 0000

0111000011101110111000101111

FPGAMicroprocessor

Hardware – Physical components

108 Computer

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

pipelined fashion. Sequential codinglanguages like C excel at capturingtemporally oriented computations.Designers traditionally capture spa-tially oriented computations in hard-ware description languages, but theyalso capture them using extensions tosequential languages, such as Posixthreads or even SystemC’s explicit cir-cuit extensions to C++. In fact, sequen-tial code coupled with knowledge ofhow a synthesis tool will convert thatcode to a circuit can capture manyspatially oriented computations. Cir-cuit designers do this all the time whenthey write loops that they know willbe unrolled, for example.

Software developers tend to excel atthe temporally oriented task of creat-ing sequential code models, like defin-ing algorithms, subroutines, and soon. But they’re typically weaker atcreating models that also involvesome amount of spatial orientation,like parallel processes, data-flowgraphs, or circuits, largely becausecomputing education in universitiestends to emphasize the former withlittle attention given to the latter. Yetwith embedded systems continuing togrow in importance, such imbalancecan’t persist much longer.

Introducing students to circuitsWhat can be done? For starters,

computing departments in universi-ties might reconsider how they intro-duce circuits to their students. Mostcomputing curricula today introducecircuits as the foundation of howmicroprocessors work, and perhapsas glue logic for interfacing physicalcomponents. But the modern com-puting curriculum should also intro-duce circuits early on as a model fordescribing computations, represent-ing a highly parallel alternative to asequential code model.

For example, a temporally orientedapproach to sorting N data itemsmakes several sequential passes overthe data, swapping certain data itemsalong the way. A spatially orientedapproach might use N/2 componentsto order pairs of data, followed byN/4 components to order quadruples

of data, and so on in a pipelined man-ner. The ways of thinking of those twocomputation approaches differ dra-matically. With the advent of multi-processors and FPGAs, who’s to saythat the spatially oriented way is anyless important?

Developing students’ spatial think-ing via computing-oriented circuitdesign, when coupled with the exist-ing developing of their temporalthinking via traditional sequentialprogramming, could lead to studentsmore easily learning parallel-pro-gramming concepts, something manywriters in recent years insist must bestrengthened. Parallel-programmingconcepts are really a hybrid of tem-poral and spatial thinking. Buildingboth temporal and spatial skillsbefore embarking on parallel pro-gramming can be thought of as build-ing both the left and right wings of aplane before attempting to fly.

M eanwhile, along with changinguniversity curricula, we all(whether in universities or

companies) can stop calling circuitshardware, and we also can broadenour use of the word software beyondjust microprocessors. In this way, cir-cuits and other modeling approacheswith a spatial emphasis can assumetheir proper role in the increasinglyconcurrent computation world of soft-ware development. ■

Frank Vahid is a professor in theDepartment of Computer Science andEngineering at University of California,Riverside. Contact him at vahid@cs.ucr.edu.

Editor: Wayne Wolf, School of Electrical and Computer Engineering, GeorgiaInstitute of Technology, Atlanta;wayne.wolf@ece.gatech.edu

Any products yourpeers should know

about? Write a reviewfor IEEE Pervasive

Computing, and tell uswhy you were

impressed. Our NewProducts departmentfeatures reviews of

the latest components,devices, tools, and

other ubiquitous com-puting gadgets on the

market.

Send your reviews andrecommendations to

pvcproducts@computer.org

today!

Tried anynew gadgets

lately?

www.computer.org/pervasive