When all hardware becomes just more software, where will the hardware engineers go-to programming school?
I've noticed over the last few years that hardware design seems to parallel software design, just delayed by about a decade. All the virtues and vices that programmers discovered in the '80s are now being uncovered by hardware engineers. High-level languages? What a good idea-for hardware. Compilers? Gee, you mean we don't have to hand-craft every single transistor? Object-oriented programming? The hardware guys are just now catching on.
Hardware design-especially for ASICs and other custom chips-is looking more and more like programming. Hardware weenies don't draw schematics any more. They generally use a high-level hardware-design language (HDL) such as Verilog or VHDL. A few lines of VHDL “code” looks a lot like a C listing at first glance. You'd never know that the language was describing hardware instead of the control flow of a program. And that's exactly my point.
The hardware-design profession is pulling itself through the same knothole that programmers did 10 years ago. Just as assembly code gave way to higher-level languages, hardware engineers are gradually discovering the joys of high-level abstraction. The benefits are much the same, but so are the pitfalls and the battles. When compiled languages first started to catch on, the “old guard” decried them as a lazy, inefficient, and unprofessional way to write software. Compilers were labeled as inelegant, generating bulky, slow, spaghetti code. “Real programmers toggle front-panel switches.”
Old-timers complained that compiled code could never be as fast, tight, or elegant as hand-written assembly code-and they were absolutely right. But it didn't matter. For all the failings and shortcomings of compilers over human assembly programmers, they are more efficient in the one dimension that matters: programmers' time. Sure, compiled programs were (and generally still are) bulkier than equivalent assembly code. Sure, compiled programs run slower. And yes, compilers have been known to produce obfuscated output that's impossible to disassemble and difficult to debug. In short, compilers make less efficient use of the computer's resources by being more efficient of the user's resources. They also have the commercially important side effect of allowing less experienced (not to say less talented) programmers to write useful and functional code.
And so it is in the hardware world. Even as we speak, the de facto standards of VHDL and Verilog are creaking under the weight of new 10-million-gate chips with multiple embedded processors and more computing power than NASA left on the surface of the moon. It's not an efficient use of the engineers' time to design a chip that big, gate by carefully crafted gate. Some faster and more productive method is required.
Third-party intellectual property (IP) was supposed to solve some of that. Hardware IP is like software libraries: you build your application up from basic functions that others have already developed and debugged. Your task is “simply” to glue the library functions together. In the hardware world, third-party IP libraries help a great deal, but gluing one vendor's processor to another vendor's Ethernet controller is tedious, error-prone work that isn't especially fulfilling and doesn't look good on a rsum.
It seems there's no skirting the fundamental issue: to design hardware circuits you have to sling gates. Or do you?
There are those who believe that designing hardware, per se, is not the real objective. The goal should be to create a system that performs a given function (VCR, handheld computer, steam whistle, or whatever). How you get there is secondary. The same sort of thinking applies (or should have applied) to the railroads in the 1880s. They focused on optimizing locomotives and boxcars while their customers were enthusiastically ignoring them and embracing automobiles and, later, aircraft. Business 101 teaches us that the railroads were not in the railroad business; they were in the transportation business. Railroads just happened to be the appropriate technology at the time. Perhaps hardware design is merely an historical anomaly.
Heresy, you say! Where would the world be without hardware engineers? Who would we blame for bugs? Besides, where will the next generation of chips come from if there's no one to design them? Hardware specialists will always be with us-it's just that their design skills will not resemble those of the engineers we work with today. Instead, chip design will become a specialized discipline of programming.
Already, a handful of companies are creating new hardware-design tools that resemble nothing so much as programming languages. Indeed, some of them are programming languages, pure and simple. They parse and compile like programming languages but the compiler emits hardware rather than software. Same input function; different output function.
An example among these is the mellifluously named Celoxica, a company in Oxford, England that produces a compiler for the language of Handel-C. Handel-C is a slight tweak of the C language. In the future Celoxica anticipates, nobody will design hardware and software separately. In fact, you won't design hardware at all. Instead, you write your program in Handel-C and compile it into a chip that runs that program. That's it. No microprocessor, no code profiling, no integrating the software with the hardware. In fact, no real software-the chip is an embodiment of the program that defined it. Voila! Suddenly all C programmers (or at least, all Handel-C programmers) become honorary chip designers.
(Note for the pedantic: obviously, Celoxica's Handel-C compiler doesn't construct actual chips. It excretes a netlist, the hardware equivalent of object code, which chip manufactures then use to fabricate the part or download into an FPGA.) Celoxica is not alone in this quixotic quest. Synopsys supports a similar approach, as do CoWare, Improv, and a number of other companies. Each backs its own particular tweaks to C, SystemC, Java, or other languages, but the concept is always the same.
The circuits that Handel-C (or SystemC, et al.) produces would make a hardware engineer gag, but that's no different from most programmers' reactions to early C compilers. Automatically generated hardware has some quirks, just like automatically generated assembly listings do. But you're not supposed to look at the output and you're not supposed to care. If you trust the tool and it works, you should look to more important tasks or you defeat the purpose of the tool.
Self-respecting hardware engineers condemn Handel-C and its ilk as miserable excuses for a CAD tool-and they're right. Using C source code to design flip-flops, multiplexers, and ALUs is unreasonable. It's like writing code using a soldering iron. But just like the initial disapproval over compilers, none of that matters. Even if the resulting circuitry looks like a kludge, it does the job and frees up the programmer's time.
There are shortcomings to this approach, to be sure. Chips designed this way aren't microprocessors, so they're not re-programmable. They're fixed-function parts designed specifically to accomplish the task defined in the program. If you want the chip to “run” a different program, you have to create a different chip.
It's also hard to integrate hardware designed this way with any outside hardware IP. The “hooks” into the circuitry are not readily apparent. A close examination of the circuits reveals little of their inscrutable purpose or how they were constructed. This makes conventional hardware types nervous when debugging time looms. And it's nearly impossible to hand-optimize anything that the hardware compiler produces.
The general weakness that all these software-cum-hardware languages share is that conventional programming languages simply can't express parallelism. There's no way to show that two functions (hardware blocks) are supposed to operate simultaneously. The C language, for example, is innately serial and has no method for expressing parallelism or simultaneity. Java supports threading, which is an improvement, so companies such as Improv advocate Java as a “universal” hardware/software design language. The trouble is, Java's an even worse hardware-description language than a programming language. Its concepts of memory, methods, and objects map just as poorly onto real hardware.
All these approaches strive to build on programmers' familiarity with existing tools and languages. But not one of those languages is remotely suitable for defining good, clean hardware. Certainly none of the currently popular languages was ever designed with an eye toward hardware description. But if you invent a new language that is good at hardware description, you defeat the purpose of leveraging familiar languages.
The hardware community is working on the problem from the other end, extending and enhancing current HDLs to give them higher levels of abstraction. These efforts, such as Superlog and System Verilog, are merely baby steps, forestalling the inevitable. But you can't blame them for trying. Their skills are at stake, if not the profession itself.
In the end, the perverted software languages are bound to prevail. There are a lot more programmers in the world than hardware engineers and the balance will probably tip still further in the future. Elegance of implementation has never triumphed over timesaving hacks. Mnemonics overtook opcodes, compilers overtook assembly, and HDLs overtook schematics. Each time, the old guard maligned the inefficiency of the automated tools vs. the craftsmanship of their methods; but each time automation carried the day.
The cost of transistors is asymptotically approaching zero while the cost of engineering talent is on a similar trajectory toward infinity. It's clear which resource is the more precious. Goodbye, elegant hardware. Hello, automated tools. And welcome, programmer, to the world of hardware design.
Jim Turley is an independent analyst, columnist, and speaker specializing in microprocessors and semiconductor intellectual property. He was past editor of Microprocessor Report and Embedded Processor Report. For a good time, write firstname.lastname@example.org.