-September 2009-
Easy to Be Hard
By Tom Cantrell, author of Circuit Cellar’s “Silicon Update” Column
Stepping out of Stanford University’s Memorial Hall for a break during the recent Hot Chips conference, I was pleasantly surprised to find John Wharton lounging on the patio enjoying the beautiful summertime day (see Photo 1). Circuit Cellar readers will recall John was one of the original architects of the 8051 MCU, a story I related back in 2004 (“’51 Flavors,” Circuit Cellar 163). By now, some 30 years after its introduction, the ’51 has found its way into untold numbers of sockets—surely billions with a capital “B”—and continues to hold a sizeable market share even to this day.
Photo 1—John Wharton, a member of the original 8051
design team at Intel, shows me his January 1978 architecture spec and one
of the first, of many, many wafers.
In a business where the market lifetime for a memory chip or PC processor is a few years, what explains the continued success of a 30-year-old design? John highlights as one reason the “Special Function Register” feature that’s made it easy to evolve and improve the ’51 with more I/O add-ons. I would also credit the fact—somewhat ironic given Intel’s hard-nosed intellectual property stance—that the ’51 is the “People’s Micro” with its design literally free for the taking. Thus, in addition to general-purpose ’51 MCUs from the likes of NXP and Atmel, we find the ’51 drafted for MCU duty in all manner of specialized chips. The ’51 is a boon for designers who have better things to do with their time and money than reinventing the MCU wheel.
Speaking of specialized chips, who should walk up, but YB Lee from WIZnet, a fabless company that sells unique “TCP/IP Offload Engine” chips. WIZnet’s latest product, the W7100, combines their TCP/IP acceleration and Ethernet hardware with—you guessed it—a ’51 MCU (see Photo 2).
Needless to say, we had an interesting impromptu discussion (one of the things I enjoy about the Hot Chips conference). John explained how way back when (i.e., before the MCU) most digital design was accomplished with TTL “gates” or dedicated chips, such as a keyboard encoder or UART, composed of said gates. The beauty of the MCU was that a single instruction in ROM (essentially wire connections) could replace many “gates,” more than enough to amortize the overhead of the processor. Indeed, using an MCU as a keyboard encoder (John wrote an app note on the very subject) was one of the first 8-bit MCU “killer apps.” And what embedded designer hasn’t used software to bit-bang a UART?
So turning to the W7100, does it make sense to push TCP/IP into hardware? After all, there are plenty of software TCP/IP stacks on the shelf, a few even designed to run on 8-bit MCUs.
The discussion—more so in the context of the Hot Chips heritage—was thought-provoking. The chips may change, but the question of hardware versus software always remains the interesting dilemma that touches almost every aspect of embedded design.
VIVA LA DIFFERENCE
I’ve asked the rhetorical question: If you see a room full of engineers staring at screens, how do you know if they’re working on software or hardware? Answer: Check if they’re wearing shoes. (I’ll be here all week.)
The point is that there’s little difference, at least on the surface, between hardware and software design anymore, notably due to the emergence of Hardware Description Languages (HDLs) and associated simulation/emulation capabilities. That’s quite a change from the old days when software was text and hardware was images (schematics, mask/PCB layouts). These days, a “hardware” designer may “type in” their design. And while most software is still text, there are even “graphical programming” tools such as National Instruments’s Labview.
Looking back, if the MCU let text (i.e., programs) do hardware wasn’t it the PAL (Program Array Logic) chip introduced in the late 1970s that breached the battle line in the other direction? Sure, PALs could be configured “graphically” in a hardware-like way by essentially “connecting the dots” (i.e., fuse map) on the chip schematic. But it wasn’t long before languages like PALASM, which allowed designers to “type in” the logic equations, took off. Now you had to start checking for shoes (see Figure 1).
Figure 1—PAL design specification. (Source: http://en.wikipedia.org/wiki/Programmable_Array_Logic
)
Fast forward to the FPGA, a device that has further blurred the difference between hardware and software. Going beyond the issue of which kind of tool is used (e.g., schematic versus HDL), the mere fact that FPGAs are so easy to reconfigure makes them more like software than a traditional chip.
You’ve probably heard the Internet catchphrase “Information wants to be free.” There’s a variant that goes “Software wants to be wrong.” Why is that? My take is that software tends to be buggy because it’s easy to hack a new revision. Contrast that with a hardwired chip where the stakes for a bug (i.e., new mask set) are extremely high.
The original premise for “sea-of-gates” FPGAs was similar to that of “sea-of-opcodes” MCUs. Yes, it’s not as efficient as dedicated hardware. But the economies of scale of producing a single chip to serve multiple applications more than offset the inefficiency.
Oh yeah? Then why is it the latest FPGAs—such as Virtex-6 that Xilinx announced at the conference—are increasingly populated with dedicated hardware? You’ll find DSP multipliers, PCI and memory interfaces, Ethernet MAC, serial transceivers, and the list goes on, growing with each generation (see Figure 2).
|
CRISC?
Computer architecture also finds itself on the horns of the software versus hardware dilemma.
Remember when RISC chips were first introduced? The claim was that a simple chip with some fancy software (some say “RISC” stands for “Relegate the Impossible Stuff to the Compiler”) was a better proposition than the hardware-intensive CISC architectures of yore.
Once again, in case you hadn’t noticed, dedicated hardware (dare I say, “Complexity”) is creeping back into favor. The latest “RISCs” feature all manner of baroque instructions that essentially devolve to hardware (the circuits behind the complex instruction) replacing software (a stream of reduced instructions). Indeed, one presentation at the conference (Convey) described a scheme whereby FPGAs are used to add application specific instructions to ’x86 processors, which are already considered “CISCy” in their own right (see Figure 3).
Figure 3—Instruction Set Innovations for Convey’s
HC-1 Computer (Source: T. Brewer,
“Instruction Set Innovations for Convey’s
HC-1 Computer,” Hot Chips 21)
Which finally brings us to the multicore march, the “Great Parallel Hope.” Here we find no less a luminary than professor David Patterson of UC Berkeley promulgating a new version of Moore’s Law that calls for a doubling of core count every technology generation, with perhaps 64 on a chip by 2015.
Of course, the problem is that people, including programmers, tend to think serially. I imagine it’s only a matter of time before somebody writes a book titled Parallel Programming Step by Step. According to Patterson, the idea of teaching the unwashed masses to program in parallel or relying on tools that “automagically” parallelize serial programs isn’t going to fly. Rather, he envisions a core of parallel programming “gurus” (less than 10% of programmers by his estimation) developing the “Parallel Programming Frameworks” that regular application programmers will rely on (see Figure 4).
|
THE HARD WAY
As John, YB, and I finished our chat, I came away feeling that the future will find hardware fighting back, whether it be the W7100s TCP accelerator, FPGAs with dedicated logic, RISCs with evermore “complex” instructions, or multicores.
I won’t go as far as to say if it can be done in hardware it should be. But the quest for ever higher performance at ever lower cost and power increasingly favors hardware solutions. Programmers are better off focusing on the application software that distinguishes their gadget from the other guys, the chrome, and tailfins if you will, rather than getting their hands dirty messing with the bare metal under the hood.
Of course, I write the “Silicon Update” column in the print magazine, so you can understand where my allegiance lies. Paraphrasing the old saying, “When your tool is silicon, everything looks like a hardware problem.”
One thing is for sure, “Software is from Mars, Hardware from Venus,” so the debate will never end.
Tom Cantrell has been working on chip, board, and systems design and marketing for several years. You may reach him by e-mail at tom.cantrell@circuitcellar.com.
Product News:
OSD-232+ is a single channel on-screen composite video character and graphic overlay device in the form factor of a 28 pin .6” dip socket. From any RS-232 or TTL source, control the display of 30 columns by 12 rows (NTSC) or 15 rows (PAL) of information directly onto an incoming composite video source.
Product News:
Debugging USB is easier
with the Beagle USB 480 Protocol Analyzer, the only analyzer with real-time
class-level decoding and support for Windows, Linux, and Mac OS X. All Total
Phase products include free software, free support, free API, and free upgrades.
See a video demonstration or download our free software today!
EQ Interactive
Problem 1—While browsing some C code, you come across an aaa.h file, which contains the following lines:
GLOBAL int aaa_function1();
GLOBAL int aaa_function2();
The corresponding aaa.c file includes the following:
#define GLOBAL extern
#include "bbb.h"
#include "ccc.h"
#undef GLOBAL
#define GLOBAL
#include "aaa.h"
What is the purpose of the GLOBAL symbol?
Problem 2—What is the Curie point of a material?
Think You Have a Great EQ Challenge of Your Own?
E-mail your best EQ question and answer
to eq@circuitcellar.com for a chance to be recognized by Circuit Cellar as an
EQ guru.
Answer 1—The GLOBAL
preprocessor symbol allows the same text in the module's header file to
function as both the declaration and definition of global symbols (functions
and variables) associated with the module.
When a module includes header files from other modules, GLOBAL expands to
extern, and each header file serves to declare the symbols from the other
modules for the current module.
When a module includes its own header file, GLOBAL expands to nothing, and the
header file serves to define that module's own global symbols. The advantage of
this approach is that there is only one file that needs to be modified when a
module's globals are changed, and separate declarations and definitions don't
need to be kept in sync manually.
Answer 2—Ferromagnetic materials lose their magnetic properties above a certain temperature that varies with the material. This temperature is known as the Curie point of the material.
Circuit Cellar Q&A: Dale Wheat
Editor’s note: Dale Wheat is a full-time freelance writer who lives near Dallas, Texas. Circuit Cellar has published seven of his articles since October 2006. See Circuit Cellar issues 195, 200, 206, 209, 226, 229, and 230. For more information, visit his personal web site dalewheat.com.
CIRCUIT CELLAR: You live in Dallas and work as a designer and freelance writer. Tell us about your previous career. When did you start this freelance endeavor?
DALE: I’ve worked in electronics and IT all my life (so far). Before heading out on my own as a full-time freelance writer, I worked as an embedded system designer and developer for a Dallas company. Before that I worked as a consultant for IBM, MCI, GTE (now Verizon), and others, as well as a couple of prison phone system manufacturers, which is a very strange market, indeed.
My focus on writing really gained momentum around 2000 when I realized that I enjoyed writing about my projects as much, or sometimes more than, the development work itself. I’ve always been a firm believer in good documentation. I appreciate it when people take the time to not only write down the bare essentials clearly and succinctly, but also give more details that help bring their projects to life.
CIRCUIT CELLAR: How long have you been designing MCU-based systems?
DALE: I was very lucky and got a very early start working with hands-on electronic and microprocessor-based projects in the late 1970s. The first embedded system I had access to was a National Semiconductor SC/MP development board with a whopping 512 bytes of ROM and 256 bytes of RAM, 110 of which were available for “user programs.” It was tethered to a 10-pound power supply and a full-sized Teletype. The built-in monitor program had all of three commands: Edit, List, and Go. What’s especially ironic is that today I work with microcontrollers that have twice that amount of program memory but only 64 bytes of RAM (i.e., the Atmel AVR ATtiny13), so it’s good that I learned how to “make do” with precious few resources. I also work with some bigger parts as well today.
CIRCUIT CELLAR: What was your first MCU-based design? Do you recall the specifics of the design?
DALE: My first MCU-based design was a Microchip PIC-based LCD interface that eventually became the PIC-an-LCD product sometime around 1997, a serial LCD which saw about a decade of popularity. I wrote about the project in Circuit Cellar 206 (“PIC-an-LCD: A Character-Based Serial LCD Controller,” 2007).
It was my first commercial PCB design, laid out without the benefit of a formal schematic. I just started putting pads and traces on the screen using a Gerber file editor and EAGLE Circuits of Garland, Texas, did the rest. BG Micro sold the PIC-an-LCD as a kit for years.
CIRCUIT CELLAR: How long have you been reading Circuit Cellar?
DALE: I avidly read Steve Ciarcia’s “Circuit Cellar” column in BYTE magazine from its first appearance. I had been reading BYTE since I first saw “Newt: A Mobile, Cognitive Robot,” (R. Hollis, Byte, Vol. 2, No. 6, June 1977). I was hooked. When Circuit Cellar branched off, I kept up with it and have been enjoying it ever since.
CIRCUIT CELLAR: Is there a recent Circuit Cellar article that was of particular interest to you? If so, why.
DALE: Every one of Robert Lacoste’s “The Darker Side” articles gets my undivided attention as soon as the magazine appears in my mailbox. His ability to present, demystify, and apply complex concepts is remarkable. Keep up the good work, Robert!
CIRCUIT CELLAR: What was the impetus for sending us your first article, “Video13: Build a Simple TV Interface”? The fame? The fortune? <grin>
DALE: It’s funny that you should ask the question that way. I was inspired by Bruce Land’s Cornell University student projects based on the Atmel AVR ATmega32. Several projects that year featured processor-generated video output in real-time, something I hadn’t imagined would be possible. So I set about to reproduce the “minimal version” that still offered some functionality, more as an educational experience than anything else. My familiarity with the Atmel AVR devices helped me select a much more modest part, the ATtiny13, to get the job done. Fitting it all in to 1K of code space and 64 bytes of RAM (as well as only 8 pins!) was a delightful challenge. Several of the architectural features of the AVR just fell into place and helped the success of the project. My early days with the SC/MP and then the Zilog Z80 surely came in handy!
At this point I had what I considered an interesting project and wanted to share it with other, like-minded individuals. It seems you agreed and published the article “Video13: Build a Simple TV Interface” in Circuit Cellar 195 October 2006—and a good relationship has evolved.
The “funny” part of your question is that my honorarium for the article far outstripped any profits I made selling the Video13 as a commercial product! It’s more of a technical curiosity than anything else, I suppose. I sold five at $5 apiece.
CIRCUIT CELLAR: Have you made any updates to the Video13? If so, do you have any photos you want to share?
DALE: “It stays as it lays,” as we like to say around here. Any updates will be in the form of a “Video48,” based on the ATmega48 or perhaps the Arduino. Batsocks in the UK have already done something similar: www.batsocks.co.uk/products/Shields/TellyMate%20Shield.htm
CIRCUIT CELLAR: Since 2006, we’ve published seven of your articles. You clearly have a strong interest in graphics, video, and things that blink. This seems obvious given your articles about the Video13 project, your character-based LCD controller (Issue 206), and your LCD digital voltage meter (Issue 209) in particular. Plus, in “Get Started With Embedded Development” (Issue 230) you write: “Let’s wrap up the ‘bare metal’ example program, show those LEDs who’s boss, and then move on to more sophisticated application development using the new CircleOS application environment.” Are graphics-related apps currently your main area of interest, or is it just a coincidence that LCDs and LEDs figure so prominently in your work?
DALE: The fascination is with what’s under the hood. The visual interface is merely a means to the end. It’s hard to get a feel for what’s happening by staring at a plastic ship soldered to a PCB. LEDs, LCDs and other display media give me the viewport I need to get to the data that interests me. Plus, I am fascinated by things that blink or beep.
CIRCUIT CELLAR: And then there’s robotics. Tell us about your start with robotics, the Dallas Personal Robotics Group (DPRG), and so on.
DALE: Growing up in the 1960s I fully expected there to be many, many more robots present in this day and age. As the Novell advertisement once read, “The future is running a little late,” or words to that effect. Where’s my rocket-pack? My TV-radio-watch? I was interested in robotics before I read the “Newt” article, but had not considered that building one myself was an achievable goal.
I attended a DPRG (dprg.org) “RoboRama” in 1998 and was inspired to build my own robots. I imagined that I had the multiple skill sets required. Let’s just say that it has been a learning experience: a truly humbling learning experience.
I have served as President of the DPRG for two years (2005, 2006) as well as Vice President and Club Librarian. There seems to be an almost limitless pool of accessible technical wizardry available within the DPRG. You should join. Bring a friend.
CIRCUIT CELLAR: What are you working on now? Do you have any interesting new projects in the works?
DALE: These days I have been scrambling to present some “Breadboard Arduino” classes at local venues. It takes about an hour to show folks how to take the component parts of a simple microcontroller circuit and hook them up on a solderless breadboard that they can then program from their PC. I find it very rewarding to see “the light come on” as people start imagining what they can do with these (now) inexpensive and accessible tools.
I’m also trying to package some slightly more powerful microcontrollers into learning solutions as complete as the Arduino, including 32-bit Cortex-M3 products as well as the support software. I’m seeing bits and pieces of it emerge in the DIY market but nothing comprehensive as of yet.
I’m also teaching people how to solder. Now that’s empowering! Ask Steve Ciarcia what his favorite programming language is. (Hint: It’s solder!)
New Book Release
Robert Lacoste’s: The Darker Side
“The Darker Side” is not just a Circuit Cellar column; it’s now a book with supplemental material that is being published by Newnes. Pre-order from Newnes Publishing and receive 20% off and free shipping. Please refer to code 96534. Order here.