SOC Design

This blog has moved

2008-06-12T20:58:00.000-07:00

A year ago, I moved this blog to http://www.edn.com/blog/980000298.html to get a wider audience and to sidestep blogspam. See you there!

Quantum Conundrum

2007-02-20T21:57:00.000-08:00

Last week, I attended the debut of what may become the first commercial quantum computer. Or not. The EDN article I wrote about this demonstration is here: http://www.edn.com/article/CA6416905.html?ref=nbsa&text=quantum

D-Wave, the company that has been developing this quantum hardware for eight years, used the Computer History Museum for it's introduction venue. However, the computer itself was located in Burnaby, British Columbia and was operated via the Internet. So we have to take D-Wave's word that we were watching an actual quantum computer solve problems. That's not to say I disbelieve D-Wave, only that I cannot say with 100% confidence that I indeed saw a quantum computer in action.

Other press outlets have published quotes that scientists are "dubious" about D-Wave's claims. I think that's the wrong word. D-Wave hasn't been forthcoming about key technical details (but says they will be in the future) so I'd say that the community is presently "unconvinced." We'd like more information before passing judgement. In the meanwhile, I consider quantum computing to be "spooky information processing at a distance," to paraphrase Einstein.

D-Wave's Orion, the name of their proof-of-concept machine, solve's NP-complete problems. These are the sort of problems that require a full solution search in conventional computers, which is a very slow process for problems with large solution sets. As it is today, Orion is about 100x slower than today's computers because it's only a 16-qubit (quantum bit) machine. By the end of 2008, D-Wave believes it can have a 1024-qubit machine running that would be 10x faster than conventional binary computers at solving NP-complete problems.

CES Update: The Revolution Will be Televised

2006-01-07T11:35:00.000-08:00

The revolution will not be televised, will not be televised,
will not be televised, will not be televised.
The revolution will be no re-run brothers;
The revolution will be live. - Gil Scott-Heron

I have just returned from the 2006 CES in Las Vegas. It was packed with people. As the volume driver in the electronics industry has switched from personal computers to consumer electronics, CES has taken the mantle as the industry's leading light into the murky future from Comdex. The mantle had previously passed from the National Computer Conference (NCC) to Comdex around 1981 when PCs started to dwarf mainframes in market dominance and NCC refused to heed the change.

The big news at Comdex, er CES, this year was a 100-year-old idea called television. New-millennium television is becoming a when-you-want-it, where-you-want-it, how-you-want-it affair. Dick Tracy had this capability in his wristwatch exactly 60 years ago. Now it seems that it's time for everyone else to have it too.

The "when you want it" phase started with VCRs in the 1970s and it has evolved into today's DVD recorders and PVRs (personal video recorders). However, all of these devices are tethered to coaxial cables tied to stuck-in-the-wall cable sockets and immobile satellite dish antennas. Also, these consumer products are only time-shifting devices; they don't jimmy with the image format and resolution. How-you-want-it and where-you-want-it boxes such as Apple's video iPod and other personal media players are just starting to appear.

As CES 2006 demonstrated, the industry is full of companies working on place-shifting and format-shifting video products. Two new classes of video place shifters I saw at CES are mobile phone handsets capable of receiving video broadcasts and boxes that cram video into IP packets and unleash them onto the Internet. LG seems to be way ahead on phone handsets that receive terrestrial and satellite video. The company was showing several video-capable handsets at CES. They just wouldn't let me shoot photos of them. So only the 140,000 other people at CES got to see them.

The other place-shifting product is epitomized by the Sling box from Sling Media. This oddly shaped box (looks like a large silver-colored bar of candy or a silver-colored gold bar to me), takes in video and spits packets out of an an Ethernet port. What you do with those packets is your business. Receive them on your computer at work, your laptop at Starbucks, or your Treo wherever you happen to be.

Both the mobile handsets and the Sling box need to reformat video to fit a target playback device that clearly isn't a conventional television receiver. Their ability to reformat images must satisfy three conflicting goals.

The video should look good.
The compression format used to send the video should consume very little bandwidth.
The amount of power required to encode and decode the compressed video should be small.

Companies that master video-compression algorithms supporting these goals will be in high demand.

Gil Scott-Heron clearly got it right in the 1970s. But in the 21st century, the revolution will be televised.

ST backs NOC for SOC design productivity

2005-12-15T09:52:00.000-08:00

From EE Times:

"ST says an effective NoC architecture will be a crucial precondition for cost-effective SoCs targeted at convergence devices and, in particular, NoC technology will play a major role in improving design productivity."

Networks on Chip

2005-12-15T09:41:00.000-08:00

Earlier this week, EDN.com published an article I wrote about networks on chip (NOCs) called "NOC, NOC, NOCing on Heaven's Door" (another song reference, this time to Bob Dylan). The article's based on some really great presentations I saw last month at the SOC conference held in Tampere, Finland. Cool place. Literally.

Pun of the day

2005-12-15T09:36:00.000-08:00

The irresistable "fish with chips" from a Reuters story as published online by MSNBC. The chips are tracking devices, of course, and are made of silicon not Idaho potatoes.

Dare to be stupid, Dare to be stupid

2005-12-15T06:14:00.000-08:00

Want to get confused? Really confused? Then take a look at this blog entry on Geek.com discussing multiple processor cores in PC-processor land. Be sure to read the comments made by the informed, the uninformed, the partially informed, and the intentionally lame.

Hopefully, SOC designers aren't nearly this confused. I also hope the advice delivered in the SOC design community isn't this, er, diffuse.

Thanks to Tensilica's Lee Vick for the pointer to the blog.

(BTW: The title of this blog entry is a reference to a Wierd Al song that apes the music of Devo.)

SOC Design: Just what do you optimize?

2005-12-14T14:51:00.000-08:00

A recent article and an unrelated analyst presentation give excellent advice to SOC designers and managers comtemplating the plunge below 100nm. The rules of system design below this lithography threshold change and the article and the presentation provide some partial roadmaps to success.

EE Time's EDA editor Richard Goering wrote a recent column on Design for Inefficiency that questions how SOC design teams trade off transistor budgets for time to market. Sound like heresy? I remind you, oh gentle reader, that precisely the same discussions about using C for embedded systems software were occurring 20 years ago. If you haven't heard, the relatively inefficient C language won over efficient assembly code precisely because of time-to-market issues. Most of today's systems would never get to market if they were solely or even largely based on software written in assembly language.

Last week at Gartner's Semiconductor Industry Briefing held at the Doubletree in San Jose, Research VP and Chief Analyst Bryan Lewis discussed "second-generation SOCs" in his presentation titled Charting the Course for Second-Generation SOC Desvices, in which he described second-generation SOCs as high-gate-count devices using mixed process technologies, multiple processors, and multiple software layers. In Lewis' vision of a second-generation SOC, the multifunctional chip is built with multiple processor cores, each driving its own subsystem with its own operating system and application firmware. This design approach is unlike today's most common design approach of loading up one main processor with as many tasks as possible, and then some.

Lewis' second-generation vision encompasses a divide-and-conquer approach to complex system design and it closely relates to Goering's theme of asking, "Just what do you optimize?" The more you burden one processor with an increasing number of tasks, the more complex the software gets and the faster the processor must run. The result: exponentially increasing software complexity (think lost time to market and bug-riddled code) and exponentially incresing power dissipation and energy consumption (think less battery life or more expensive power supplies; noisy, expensive, and relatively unreliable cooling fans; and larger, more costly product enclosures).

Once again, the question of the decade is: "What do you optimize?" Do you optimize transistor count to absolutely minimize chip cost while greatly increasing design time and cost and possibly missing market windows, or do you waste truly cheap transistors to buy back some of that time?

I think the answer's pretty clear: 90nm and 65nm transistors are cheap and engineering time is expensive. Lost time to market is virtually priceless. What do you think?

More wisdom from Jack

2005-12-14T14:46:00.000-08:00

Jack Ganssle, who writes for Embedded Systems Design and Embedded.com almost always has interesting things to say. His latest column on NRE versus cost of goods sold is no exception. See it here. Although Jack is writing about purchased software in his column, his arguments are equally applicable to IP blocks for SOC designs.

The Lessons of History

2005-12-01T09:01:00.000-08:00

Lessons of history from Leslie Berlin’s “The Man Behind the Microchip: Robert Noyce and the Invention of Silicon Valley”

Everyone knows, and no one remembers, that history repeats itself. This maxim is true even in the short history of the electronics industry. Here are a few excerpts from Dr. Leslie Berlin’s Bob Noyce biography, “The Man Behind the Microchip,” that serve as gentle reminders:

1. The time is late in 1949, two years after Bell Labs announces the creation of the transistor. Bob Noyce has just started his first year of graduate studies at MIT:

“… [Wayne Nottingham’s] Physical Electronics seminar might well have been Noyce’s only direct instruction on the topic [transistors] that year, for MIT had yet to incorporate the transistor into its formal curriculum. Nottingham’s Electronics class, for example, did not mention the device at all in 1949. The transistor was a new technology, and it had very real problems. It was hard to build a functional point-contact transistor; indeed, simply replicating the Bell team’s results was difficult. Vacuum tubes, by contrast, were entering their heyday: they were far cheaper and more stable than ever before. No one—certainly not Nottingham—saw any evidence to indicate that the point-contact transistor would be in a position to replace tubes for a long, long time.”

Within the next 10 years, Bob Noyce would join the transistor research group at Philco; in 1956 he would then leave Philco and join Shockley Transistor Labs in Palo Alto; and then less than two years later he would found Fairchild Semiconductor with seven other Shockley refugees/traitors. In 1959, only 10 years after Noyce started his MIT graduate work, Fairchild’s Jean Hoerni would develop the planar process with its protective coating of silicon dioxide, which tremendously boosted transistor ruggedness and reliability and gave Noyce the missing piece of the IC puzzle. Hoerni’s development of the planar process enabled the invention of the integrated circuit and is the bedrock foundation of all semiconductor manufacturing more than 40 years later. Today, we take transistors for granted, but in 1949 they were weak, unreliable laboratory curiosities with no hope of competing against five decades of vacuum tube R&D.

2. The year is 1961. In March of this year, Fairchild Semiconductor introduced the first integrated circuits, dubbed Micrologic:

“The reaction was gratifying but did not translate into widespread adoption. By the end of 1961, Fairchild had sold fewer than $500,000 of its Micrologic devices, which were priced at about $100 apiece. Texas Instruments, the only other major supplier, was having such problems selling integrated circuits that it cut prices from $435 to $76 in 90 days. The move had little effect.

Customers’ objections to integrated circuit technology abounded. The devices were extremely expensive relative to discrete components—up to 50 times the cost for comparable performance, albeit in a smaller package. Many engineers, designers, and purchasing agents working for Fairchild’s customers feared that integrated circuits would put them out of work. For decades, these customers had designed the circuits they needed from off-the-shelf transistors [and vacuum tubes before transistors], resistors, and capacitors that they bought from manufacturers like Fairchild. Now Noyce wanted to move the Fairchild integrated circuit team into designing and building standard circuits that would be sold to customers as a fait accompli. If the integrated circuit manufacturers designed and built the circuits themselves, what would the engineers at the customer companies do? Moreover, why would a design engineer with a quarter century’s experience want to buy a circuits designed by [a] 30-year-old employee of a semiconductor manufacturing firm? And furthermore, while silicon was ideal for transistors, there were better materials for making the resistors and capacitors that would be built into the integrated circuit. Making these other components out of silicon might degrade the overall performance of the circuits.

As late as the spring of 1963, most manufacturers believed that integrated circuits would not be commercially viable for some time, telling visitors to their booths at an industry trade show that ‘these items would remain on the R&D level until a breakthrough occurs in technology and until designs are vastly perfected.’”

In the spring of 1964, Bob Noyce started selling Micrologic flip-flops for less than the cost of the discrete components needed to build an equivalent flip-flop, and for less than the manufacturing cost of the IC:

“Less than a year after the dramatic price cuts, the market [for ICs] had so expanded that Fairchild received a single order (for half-a-million circuits) that was the equivalent of 20 percent of the entire industry’s output of circuits for the previous year. One year later, in 1966, computer manufacturer Burroughs placed an order with Fairchild for 20 million integrated circuits.”

“By the middle of the 1960s, Fairchild was one of the fastest-growing companies in the United States.”

Today, we take the integrated circuit and Moore’s Law for granted, but in the early 1960s, their future was anything but sure.

3. By 1968, Bob Noyce was fed up with the management at Fairchild Camera and Instrument, the parent company of Fairchild Semiconductor. He and Gordon Moore incorporated a company called NM Electronics in July, 1968. NM Electronics would become Intel by the end of the year.

“Just as the industry’s high hopes for integrated circuits had launched the earlier gaggle of startup companies, the 1968-1969 generation was inspired by a belief that semiconductors were on the cusp of another dramatic technological breakthrough… Already, Moore’s own R&D group at Fairchild had fit a once-unthinkable 1,024 transistors onto a single circuit. In 1968, this circuit was little more than a lab curiosity, but the general consensus held that circuits with more than 1,000 components integrated together—so-called Large Scale Integrated circuits—should be physically possible to mass produce by 1970.”

However, large-scale integration (LSI) was certainly not considered a slam-dunk technological leap in 1968:

“… Noyce and Moore, in fact, had settled on computer memories as a first product not primarily because the computer market was growing—although that was a welcome reality—but because memories would be the easiest types of LSI circuits to build. … In Moore’s words, LSI was a “technology looking for applications” in 1968. Which is to say: if LSI technology was going to work anywhere, it would work first in memories. If it worked in memories, Noyce and Moore could anticipate an ever-growing market of computer makers ready to buy.”

The plan therefore, was to replace core memories with semiconductor memory. Core memory, developed in the early 1950s, pervaded computer design in the late 1960s. Mainframes and minicomputers used core memories because there simply was no alternative memory technology that could compete with core memory on the basis of cost/bit, energy consumption, or size. Even so, core memory was vulnerable to attack if a superior, more cost-effective technology could be developed:

“Magnetic cores had their shortcomings, however, and in these Noyce and Moore had seen a potential foothold for Intel. Cores were not a particularly fast means of storing data. … Moreover, the core memories were built by hand. Every one of those iron donuts was individually strung on a wire by a woman in a factory, most likely in Asia. Noyce and Moore knew that this labor-intensive means of production was not sustainable for a computer market growing exponentially, just as they had known a decade earlier that hand-wired discrete components could not serve the exploding market for space-age electronics.”

Even with these shortcomings, Noyce and Moore knew by now that not all technological improvements are immediately hailed by design engineers:

“Moore and Noyce knew that the problems with cores were irrelevant to most computer engineers, who did not spend their time thinking about how they would build their machines ten years in the future. These engineers cared about how their computers work now, and so the cost advantages of semiconductor memory would have to be overwhelming before engineers would consider abandoning the clunky, but reliable, magnetic cores. A sense of déjà vu may again have struck Noyce and Moore, who faced a similar obstacle when they initially brought the integrated circuit to market. Noyce, the architect of Fairchild’s decision to sell integrated circuits below cost to get a foothold in the discrete components market, was betting a similar strategy would work for semiconductor memories.”

These first memories weren’t easy to manufacture, and the low yields didn’t allow them to be sold cheaply. Intel’s first MOS memory, the 256-bit 1101 static RAM (SRAM), was too slow and expensive when it was introduced in September, 1969. At 20-60 cents/bit, it was 5x to 12x more expensive than core memory per bit. Even reducing the price of the 1101 by 75% didn’t help sales.

However, Intel pressed on and introduced the 1-Kbit 1103 dynamic RAM (DRAM) in October, 1970:

“To be sure, the device was far from perfect. Among the 1103’s many failings known to Intel was the fact that, in Andy Grove’s words, ‘under certain adverse conditions, the thing just couldn’t remember’—a problem for a memory. Some 1103s failed when they were shaken. A few developed moisture under the glass used to seal them. Often no one knew why the devices would stop working. The problems inspired Ted Hoff to write a 28-page memo explaining the 1103’s operation and quirks.

Andy Grove had nightmares that boxes and boxes of 1103s would be returned to the company for defects—and would run Intel entirely. Gordon Moore, on the other hand, wondered if, in some perverse way, the 1103’s problems made it easier to convince customers to use the device. Engineers who specialized in core memories recognized analogs in the 1103. Both suffered from voltage and pattern sensitivity. … ‘All these things made the 1103 more challenging and less threatening to engineers [at customer companies],’ Moore explains. ‘We did not plan it to happen this way, but I think that if [the 1103] had been perfect out of the box, we would have had a lot more resistance [to it] from our customers.’”

By 1972, Intel was building 100,000 1103 DRAMs per year and was still unable to meet demand for the device, even with a Canadian second source that had paid Intel millions of dollars for the second-source rights to the device. Essentially, all of Intel’s 1972 revenue, $23.4 million, came from sales of the 1103.

4. Today, Intel’s no longer in the memory business—microprocessors are now the company’s bread and butter. Intel entered the microprocessor business completely by accident. It then took a lot of missionary work before the microprocessor became a successful product category:

“Intel’s microprocessor story opens in the spring of 1969, around the time that [Gordon] Moore called [Bob] Noyce in Aspen to tell him that the MOS team had a working silicon-gate memory. A manager from a Japanese calculator company called Busicom, which was planning to build a family of high-performance calculators, contacted either [marketing manager] Bob Graham or Noyce to ask if Intel, which had a small business building custom chips designed by customers, would like to manufacture a chip set that would run the calculator. Calculator companies around the world were seeking out semiconductor companies to build chips for their machines, and Noyce said that Intel was nearly the only manufacturer left who had not already agreed to work with a calculator company. … Busicom, which was designing a particularly complex calculator, wanted a set of a dozen specialized chips with 3,000 to 5,000 transistors each. Busicom planned to send a team of engineers to Intel to design the chips on-site and would pay Intel $100,000 to manufacture its calculator chip sets. Busicom expected to pay Intel about $50 for each set manufactured and promised to buy at least 60,000 of them. Intel agreed to this arrangement.”

Noyce made Ted Hoff, Intel’s resident computer expert, the company liaison to the Busicom design team. Hoff did more than he was assigned. He took a technical interest in the Busicom design and soon concluded that disaster was on the horizon. The projected transistor count for each chip was beyond the state of the art and the large number of chips in the set was going to drive the component cost well above the $50 target.

Hoff developed an alternative scheme based on a general-purpose programmable chip that would act like a small computer processor. This device could then be programmed using memory devices (Intel’s primary intended product line at the time) and the whole Busicom system could then be built using far fewer device types. The programmable device, of course, was a microprocessor. Hoff tried to convince the Busicom engineers to shift their direction, but he failed to convince them.

Consequently, Hoff went to Noyce and convinced him. Noyce told Hoff to go off and develop his idea, just in case the predicted disaster materialized. By August, 1969, Noyce wrote to the president of Busicom and took Hoff’s position. There was no way that Intel would be able to manufacture the chip set currently under development and sell it to Busicom for $50/set. Noyce estimated that the price would be more like $300/set. He asked if Busicom still wanted to continue the project.

In September, Bob Graham sent a similar letter but also suggested that Intel had developed an in-house alternative that might better meet Busicom’s cost target. Busicom sent two executives to Intel in October. They considered the alternatives and chose Intel’s approach, with a projected cost of $155/chip set. Then, Hoff and Intel did nothing. The agreement wasn’t signed until February, 1970. In March, 1970, Busicom sent a “How’s it going?” letter to Intel. Only then did Intel hire Federico Faggin to work on the microprocessor’s design. In nine short months, he designed and then produced working samples of the four chips in the Intel calculator chip set.

However, the calculator market had gotten competitive and Busicom indicated that it wanted to negotiate a price reduction, even before volume production started. Noyce asked Hoff for advice on the contract renegotiation. Hoff said to place highest priority on the right to sell the chips to other customers. The renegotiation was stalled until August, 1971 and finalized in September. Intel had gotten the right to sell the microprocessor, which it introduced as the 4004 in November, 1971, a month after Intel’s IPO.

However, the microprocessor was not an overnight sensation. For example, Noyce foresaw the microprocessor’s use in automobiles and went to General Motors in 1971 to talk about adopting microprocessors for automotive applications. GM already had an automotive electronics program underway but the GM execs were skeptical that someting as advanced as Intel's computer-on-a-chip would be controlling vehicle brakes or anything else inside of a car soon.

“… Noyce almost certainly told them, their skepticism was well grounded. No one would want the 4004 controlling brakes in production cars; the device was too slow and too rudimentary for general use. And its successor, the 8008 (introduced in April 1972) was not much better.

But Noyce was not trying to sell 4004s or 8008s to General Motors. He was starting conversations that he expected would only bear fruit years later. He knew he was contending with entrenched ways of thinking and years-long design cycles. He felt confident that by the time these customers were prepared to experiment with microprocessors, the technology would have caught up with his visions for it. And indeed it did.”

The Silicon Steamroller

2005-10-06T07:35:00.000-07:00

In an October 5 article, EE Times' editor Dylan McGrath writes: "There is a widespread misconception about the current size and strength of the Chinese fabless semiconductor industry, according to Lung Chu, president of the Asia Pacific region for Cadence Design Systems Inc...

Chu said total revenue for Chinese fabless companies in 2004 was less than $1 billion and that most of the companies' designs are 0.18 micron or 0.25 micron."

So, things look pretty good still for the rest of the world, which seems to hold the high ground of advanced semiconductor design. That is, until you couple this October 4 story about IC mask making written by Richard Goering, also for EE Times. Goering writes about this year's version of an annual mask-usage study sponsored by Sematech and conducted by Shelton Consulting:

"Only 5 percent of IC photomasks are below 100 nm...according to a 'mask industry assessment' study presented at the BACUS Photomask Technology symposium... According to the study results, just under 50 percent of masks use 350 nm or greater ground rules, 12 percent are below 130 nm, 5 percent are below 100 nm and just 0.8 percent are below 70 nm. The study looked at volumes, not revenues or IC transistor counts."

Using these numbers, by my count Chinese fabless design companies can already handle well over 50%, and perhaps as much as 80%, of the designs being created today. That fraction will increase rapidly over the next few years as the design houses in China climb the design learning curve.

As a country, China has proven many times over that it can steamroller any learning curve it wishes. The only way to avoid being crushed by a steamroller is to find a way to run faster than the steamroller or find a faster vehicle to escape. It's foolish and dangerous to think that the steamroller will run out of fuel before it can reach you.

Moore's Law Moves Along

2005-10-03T23:35:00.000-07:00

EE Times reports the first public announcement of a 65nm tapeout by Silicon and Software Systems (S3). It's a 500-MHz chip intended for consumer devices and is expected to ship in very high volumes, hence the desire to use 65nm design rules to minimize the silicon real estate. The chip was designed with Cadence tools.

Is the end near?

2005-09-01T13:44:00.000-07:00

Today's Electronic News carries an interview with Rick Hill, chairman and CEO of IC-manufacturing equipment supplier Novellus. Hill says that 65nm manufacturing technology looks like the economic end of the road for lithography shrinks because we're getting perilously close to tolerances measured in single atomic layers and we're using charge packets composed of very few electrons to represent ones and zeroes. Thoughtful reading.

More on Multicore Design

2005-08-30T13:10:00.000-07:00

Market research firm IDC in Framingham, Massachusetts has declared that IC design using multiple processor cores may be one of the most significant industry developments of the past 40 years.

The IDC study is called "Multicore Processing Scenarios, 2005-2009: Disrupting the IT Market in Three Generations?" (IDC #33789).

Two cores, four cores, eight cores, and so on

2005-08-29T14:29:00.000-07:00

Last week at the Intel Developer Forum in San Francisco, Intel’s President and CEO Paul Otellini estimated that his company would ship over 60 million dual-core Pentium processors over the next 18 months. He also said that the company has ten quad-core projects in the works. Intel has gotten that good ole’ multi-core religion big time, following AMD’s lead with its dual-core Opteron. Although big doings in the PC space often lead to similar developments in the embedded-systems arena, this time the PC processor giants are playing catch-up with the embedded league.

There are many technical reasons for going to multiple processor cores. First, this approach allows the system design to cut clock rate and thus operating power. Cut clock rate by 50% and a variety of factors will result in a power reduction of more than 50%, which more than makes up for the extra power needed to run the added processor.

Cutting the clock rate eases memory-access timing, which is another big plus for system designers. Cutting clock rate also allows the chip designers to back away from the bleeding edge of IC-fabrication technology. These factors cut manufacturing costs.

Finally, adding more processor cores to a chip allows IC designers to do something really useful with all of those extra transistors Moore’s Law keeps dumping on our doorsteps. Instead of spending these transistors on increasingly complex processor architectures that get only a few percent faster for the effort, adding another processor core can substantially boost system performance, if the system software is written correctly.

Intel’s and AMD’s move towards multiple-core processors is potentially good news for embedded system designers because PC programmers, a group larger by far than embedded-system programmers, will start to think in terms of getting tasks done with multiple processors. We will start to leave the “one-big-processor” paradigm behind. Because many embedded-systems programmers first learn their craft on PCs, this trend bodes well for all system design.

Al's Story

2005-07-15T14:50:00.000-07:00

My friend and neighbor Al has been in the electronics business a bit longer than I have. I spent a week traveling all over Western Nevada with Al two weeks ago, so we spent a lot of time in the car together. Al told me that one of his first jobs was to develop a transistor tester to characterize the hand-made junction transistors his company was getting from RCA, Philco, and other vendors. Transistor-to-transistor device characteristics varied wildly back then because transistor manufacture was pure alchemy in the 1950s.

Another job Al had in that era was to linearize some signals. Al told me it was pretty tough to do this back then. All he had to work with was resistors, capacitors, diodes, and discrete transistors.

Last week, I read about a new microcontroller from Zilog called the Z8 Encore XP, which would have made this job much easier. The Z8 Enxore XP is based on the 8-bit Z8 processor core, which I recall using to design the electronics for a total-organic-content water analyzer back in the early 1980s.

Today's Z8 processor comes packaged in an 8-lead SOIC and costs around a dollar. In addition to the processor core, the Z8 Encore XP includes four 10-bit A/D converters and 4K bytes of flash memory on chip. You program it in C. If I could go back 50 years to tell my friend Al that I could do a piecewise linearization of four of his signals to about 0.1% for a buck (that would be linearization for 25 cents per signal), and that I could get a prototype running in a day, I wonder what he'd say.

The point in telling you Al's story is to remind you that no technology stands still. Consequently, your approach to system design can't stand still either. We all chuckle a bit about Al's predicaments 50 years ago because we have far more advanced ways of dealing with the problems he had to solve using much cruder tools.

However, is Al's situation still funny when you're using the same SOC design techniques that you used 10 years ago?

To infinity and beyond!

2005-07-15T13:38:00.000-07:00

The title quote is from Buzz Lightyear but the topic of this post is David Lammer's cover article on 65nm process technology in the July 11 EE Times. The article is about the 2005 Symposium on VLSI Technology held in Kyoto, Japan last month. A few points in this excellent article caught my eye with respect to system design.

Point one: 65 nm technology buys you a cool 10 million transistors per square millimeter! An economical chip is around 100mm squared, which works out to one billion transistors on the chip. Even a cheap 5x5mm chip made with 65nm technology carries 250 million transistors. Hand-coding enough RTL to fill these chips will take, like, "To infinity and beyond!" You'd better get ready to find a more efficient way to design chips.

Point two: If you sniff at point one and say that leading-edge 65nm process technology is only for high-priced, cutting-edge products, read the statement from Mark Pinto, Chief Technology Officer at Applied Materials: "Demand from China is only going to grow—and 65nm is absolutely ideal for consumer chips aimed at growing markets."

Point three: Srini Raghvendra, Senior Director of Design For Manufacturing at Synopsys said: "Design productivity, measured in terms of gates per engineering workday, must improve fourfold at 65nm over the 130nm node." Do you have a plan to achieve that?

Point four: Process technology, especially at the 65nm node and future nodes, will no longer provide the automatic power reductions that "classical" Moore's-Law scaling has delivered for the past 40 years. "Addressing the problem requires architectural, system-level decisions." said Eric Filseth, a Cadence marketing manager.

Point five: Hardware/software codesign becomes more crucial at 65nm. "Teams must start on software creation at the same time that RTL design commences." according to Tohru Furuyama, general manager of R&D at Toshiba's SOC engineering center in Kawasaki, Japan.

Point 6: Mask costs for 65nm chips are estimated at $3 million. That's still small compared to the cost of designing a chip with as many as a billion transistors, but it's not an insignificant sum. You'd better have some good simulation models that will run your application code before you tape out a mask set.

Point 7: Process variations can occur across a single die at the 65nm node, which means that more functional chips can be out of spec. To weed these out, you will need more at-speed testing, which means more built-in self testing (BIST) because otherwise, you can count on leaving these chips on testers for an hour apiece. Do you have a plan to add BIST to your designs? You'd better.

All of these issues are addressed by processor-centric SOC design. If you haven't yet read Engineering the Complex SOC by Chris Rowen and Steve Leibson, this would be a good time to do so. We keep a nice writeup on the book on the Tensilica Web site if you need more information.

Rumors of RISC's demise somewhat premature

2005-07-11T15:28:00.000-07:00

This week in EE Times, Ron Wilson writes about a keynote given by MIPS CEO John Bourgoin lamenting the demise of RISC processors (MIPS' main product). When the idea of RISC's clock-per-instruction concept started in the 1980s at IBM, processor clock cycles and memory access times were near parity so the RISC concept made sense for minicomputer and mainframe processor design. RISC processor design eschews complex, multiclock processor instructions and essentially replaces microcode ROM with single-cycle instruction RAM caches and optimizing compilers.

Even the most successful CISC instruction set ever invented, that of the 8086 microprocessor and its descendants, became "RISC-ified" in the 1990s. Inside modern x86 processors, an instruction chopper/shredder (see the end of the movie "Galaxy Quest" for a vivid visualization of this device) finely slices the CISC x86 instructions into simpler operations that are then distributed to one or more RISC engines hidden deep inside the machine.

Today's problem with the RISC concept, which Wilson addresses, is that memory access time is now much slower than today's processor clock cycle times, at least for DRAMs. The result is a heavy reliance on increasingly large SRAM caches that continue to keep up with processor clock rates, barely.

However, this situation is not strictly the fault of RISC's pipelined one-instruction/clock approach. The problem is caused by another RISC fault, the reduction in the number and complexity of instructions to a basic set of less than 100 instructions. Compilers can indeed create instruction streams that perform complex tasks from these simple instructions, but it takes a lot of instructions to do so. If complex programs require many instructions to function, then they need larger caches and higher clock rates to meet performance goals. Larger caches and higher clock rates ultimately increase product cost.

Enter post-RISC configurable processors. With such processors, design teams can add specialized, task-specific instructions to the processor that function like CISC instructions (by doing complex things) but adhere to RISC's pipelined, one-instruction/clock approach. These processors work well as deeply embedded task engines inside of SOCs where task specificity is easy to define and appropriate to use. In such applications, programs are typically small and do not require large caches. In addition, specialized instructions reduce the number of instructions needed to perform the target tasks, which relieves the pressure to constantly boost clock rate.

In short, RISC (like the dinosaurs) isn't dead, it has evolved.

Go to the Processor Forum, now!

2005-05-06T16:57:00.000-07:00

Anyone working on SOC development needs to know about the latest advances in processor technology and design. The place to get a concentrated dose of processor education is the upcoming Spring Processor Forum, held in San Jose at the Doubletree Hotel this year on May 16-19. Go sign up. Tell 'em Steve sent you.

Wim Roelandts: ASICs will never die

2005-05-06T13:38:00.000-07:00

For a good interview with Wim Roelandts, CEO of Xilinx, check out this article written by Ed Sperling at Electronic News. Instead of the usual FPGA bravado about taking over the world, Roelandts gives a very realistic picture of the FPGA versus ASIC design decision process as well as a good summary of Moore's Law and its immediate future.

The humbling elegance of butterfly navigation

2005-05-06T09:08:00.000-07:00

Two scientists at the University of Massachusetts Medical School have discovered how Monarch butterflies navigate over thousands of miles between the US and Mexico during their annual migrations. The butterfly's eyes contain photoreceptors that are tuned to receive polarized UV light from the sun. These receptors are directly linked via neural fibers to a region of the butterfly's brain called the dorsolateral protocerebrum, which contains a circadian clock that controls the butterfly's metabolic cycles. By neurally combining the time of day and the incident angle of UV light from the sun, the Monarch's brain computes a compass heading in real time.

The next time you think you've designed a really "hot," complex embedded system, consider how difficult it still is for human designers to develop something as elegant and complex as the Monarch's migratory navigation system. Also, consider how you'd power such a system on fruit nectar and water.

More advice on designing multiprocessor SOCs

2005-05-06T07:48:00.000-07:00

Earlier today, I wrote up Jack Ganssle's article on the software aspects and advantages of multiprocessor SOC design. TI Principal Fellow Gene Frantz has written up some good guidelines on how to develop multiprocessor SOCs in EE Times. Worth a look.

Build complex SOCs faster and cheaper

2005-05-06T07:35:00.000-07:00

I've written before about the great articles authored by my good friend Jack Ganssle. He's a very popular engineer/writer with a better handle on embedded software issues than anyone else in the business. His latest article in Embedded Software Programmaing magazine, Subtract Software Costs by Adding CPUs, provides real meat in the form of quantitative substantiation to a gut feel that I've had for a while. Specifically, Ganssle's numbers show that you can get a system-level project out the door a lot faster by chopping the software into manageable pieces and assigning the pieces to a number of independent, intercommunicating processors.

There are many advantages to this approach. First, each piece of software can be written by a much smaller design team with much less communications overhead between team members. Second, you don't need one monster processor running at multiple gigahertz to execute all the code. Several smaller, slower processors can do the job in a less costly IC fab process and at much lower power. And third, this approach seems to cut the bug rate on embedded code.

RAW deal—duel of the digicam file formats

2005-04-27T09:07:00.000-07:00

As the “digitization of everything” continues at breakneck speed, one of the real success stories is the rapid replacement of film cameras with digital versions. At the top of the digicam pyramid reside the digital SLRs (“dSLRs”) made by Canon, Nikon, Olympus, Pentax, etc. Although almost all digicam’s produce images in standard file formats (JPEG and/or TIFF), the dSLRs can also record images in an uncompressed format known as “RAW.” Photo professionals and top-end photo enthusiasts prefer the RAW format because it can produce pictures with the greatest resolution and color depth and it avoids all compression artifacts. However, every digicam vendors’ RAW format is proprietary and different.

Consequently, every digicam vendor that makes cameras with RAW file capability must offer a proprietary RAW converter program so that their RAW images can be converted to the standard file formats at some point. In addition, vendors of image-editing and image-manipulation programs such as Adobe, Bibble Labs, and DxO offer their own homegrown RAW converters, but not for every camera.

As dSLRs evolve, the problem of proprietary RAW formats grows and the professionals and enthusiasts in the dSLR market are increasingly up in arms about proprietary formats. Most recently, Nikon has marketed itself straight into the crosshairs of what may well turn out to be a shooting war. Nikon has drawn fire because it is encrypting the white-balance data in its RAW files (called Nikon Electronic Format or NEF files) from the Nikon D2X and D2Hs dSLRs (as reported in dpreview.com, the Engadget blog, ). This encryption effectively cripples third-party image-processing programs and forces users of those two cameras to employ Nikon’s own Nikon Capture program (sold separately). Nikon has an SDK that converts NEF files into standard image files that can be processed by third party programs. Nikon says it will license the SDK to what the company calls “bona fide” software developers, but the encryption has been cracked by at least two developers, although such actions may open the third-party developers to prosecution under the Digital Millennium Copyright Act (DMCA).

There are some signs of sanity on the horizon. One of the first is the openRAW project, an attempt to get digicam manufacturers to openly document their RAW formats for the benefit of the entire photographic industry. Adobe is taking a different tack, trying to drum up support for a universal RAW format that it introduced last year called the Digital Negative (DNG) format, which is based on the TIFF 6.0 standard. Here’s hoping the imaging mavens wake up sooner rather than later.

Shoe Biz Redux

2005-04-26T16:51:00.000-07:00

Last month, I wrote about German shoe maker Adidas' new, $250, computerized Adidas 1 running shoes that automatically and continuously adjust the shoes' cushioning based on the runner's gait. Each shoe has a 5-MIPS processor in it (presumably there's a left processor and a right processor). Each processor accepts feedback data from a magnetic impact sensor, computes the "optimal" amount of cushioning using a "proprietary" algorithm, and drives a small electric motor that adjusts the shoe accordingly. It turns out that a real runner can feel the difference. For a positive, hands-on (feet-on?) review of the Adidas 1 shoes, see Frank Bajak's MSNBC article online.

For a nice exploded diagram and technical explanation of the shoe, click here.

To a terahertz and beyond

2005-04-26T10:00:00.000-07:00

This month, two researchers working at the Micro and Nanotechnology Laboratory at the University of Illinois Urbana-Champaign announced that they have pushed transistor operating frequency more than halfway towards a terahertz. Developed by physicists Walid Hafez and Milton Feng, the pseudomorphic HBT (heterojunction bipolar transistor) has a maximum operating frequency of 604GHz. It’s fabricated from indium phosphide and indium gallium arsenide.

The researchers have been developing increasingly fast transistors; Two years ago, they broke the 500GHz barrier. Before this latest development, the team’s fastest transtor operated at 550GHz and operated at 176 degrees C. As always, heat is a big issue with high-frequency transistor operation. According to Hafez, "Projections from our earlier high-frequency devices indicated that in order to create a transistor with a cutoff frequency of 1 terahertz, the devices would have to operate above 10,000 degrees C. By introducing grading into the layer structure of the device, we have been able to lower the potential operating temperature for a terahertz transistor to within an acceptable range."

The 604GHz transistor surpasses what was previously the world’s fastest transistor, a 562GHz HEMT (high electron mobility transistor) FET developed in 2002 by Akira Endoh at Fujitsu Laboratories. Endoh and his colleagues are also shooting for a terahertz and beyond.

Live Law, Dying Corollaries

2005-04-20T09:18:00.000-07:00

Yesterday marked the 40th birthday of Moore’s Law. Electronics magazine published Moore’s first article on the topic of device scaling in semiconductors on April 19, 1965. In the ensuing 40 years, the number of components we can fabricate on a production integrated circuit jumped by a factor of more than one million. On average, that’s better than a 10x increase in device count every decade and we can expect at least another 10x before hitting hard limits set by the size of silicon atoms.

However, just because Moore’s Law seems alive and well doesn’t mean that everything is fine in the land of the ever-shrinking transistor. Two corollaries of Moore’s Law—often mistaken for the real thing by the press—are clearly dying. Those corollaries relate to device speed and power dissipation. For nearly 40 years, smaller transistors also meant faster transistors that ran on less power, at least individually. Those corollaries started to break somewhere around the turn of the century.

Nowhere is this effect more apparent than in the 25-year fight for the fastest clock rate in the world of PC processors. Intel and AMD have been locked in a PC-processor death match for more than 20 years and, for most of that time, processor clock rate largely determined which company was “winning” at any given time. (Actually, Intel’s always winning when it comes to sales but the competition has wavered back and forth with respect to technology.)

In the early 1980s, Intel signed a cross-license agreement with AMD for manufacturing x86 processors starting with the 8086 and 8088. Intel then introduced the 80286 at 12.5MHz. AMD, being the second source, sought a sales advantage over prime source Intel and found one by introducing a faster, 16MHz version of the 80286. Intel fought back with its 80386, which ran at 33MHz, and refused to hand over the design for that processor to official second source AMD. This naturally led to a lawsuit.

Meanwhile, AMD fought back on the technological front by introducing a reverse-engineered 80386 running at 40MHz. The race went on for years. In 1997, AMD’s K6 processor hit 266MHz and Intel countered by introducing the Pentium II processor running at 266MHz just three weeks later. Three years later, AMD’s Athlon processor was the first x86 processor to hit a 1GHz clock rate.

Finally, Intel really got the message about clock rate. Clock rate was clearly king in the processor wars. As a result, Intel re-architected the Pentium’s microarchitecture to emphasize clock rate (though not necessarily real performance) by creating a really deep pipeline and the resulting Pentium 4 processor put Intel substantially ahead in the clock-rate war.

All of these clock-rate escalations relied on Moore’s-Law scaling to achieve the added speed. Faster clock rates automatically accompanied smaller transistor designs through the 1970s, 1980s, and 1990s. However, this isn’t true any more. Intel and AMD are no longer trying to win these clock fights because that war is essentially over.

Additional Moore’s-Law transistor scaling produces smaller transistors, so that more of them fit on a chip. But these shrunken transistors don’t necessarily run any faster for a number of technical reasons and they also don’t run at lower power due to related factors. There are some additional processing tricks such as strained silicon and SOI that can achieve higher clock speeds, but they no longer come as an automatic benefit of Moore’s Law.

There’s been another casualty of the clock-rate war: power dissipation. The original IBM PC ran its 8088 microprocessor at 4.77MHz and required no heat sink. The 80286, 80386, and early ‘486 processors also ran without heat sinks. Around 100MHz, PC processors started requiring heat sinks. Eventually, they required heat sinks with integrated fans. Some high-end PCs now come equipped with active liquid-cooling systems for the processor. This isn’t progress because fans add noise and have reliability issues of their own. However, these processor fans are essential because it’s become very difficult to extract the rapidly growing amount of waste heat from these processors as the clock rate has climbed.

Consequently, Intel and AMD are moving the PC-processor battlefront from clock speed to parallelism: getting more work done per clock. Multiple processors per chip is now the name of the game. Coincidentally, this week, during the 40th-anniversary celebrations of Moore’s Law, both Intel and AMD are announcing dual-core versions of their top-end PC processors. The companies have concluded that faster performance through mere clock rate escalation is a played-out tune. However, Moore’s Law is still delivering more transistors every year so Intel and AMD can put those numerous, smaller transistors to work by fabricating two processors on one semiconductor die.

None of this is new in the world of SOC design because SOC designers have never been able to avail themselves of the multi-GHz clock rates achieved by processor powerhouses Intel and AMD. SOC design teams don’t have hundreds of engineers to hand-design the critical-path circuits, which is the price for achieving these extremely high clock rates. However, all SOC designers can avail themselves of the millions of transistors per chip provided by Moore’s Law in the 21st century. As a result, many companies have been developing SOC designs with multiple processors for several years.

The International Technology for Semiconductors Design Technical Working Group (ITRS Design TWG) recently met in Munich to discuss changes to the next official ITRS. Part of that discussion involved a forecast in the increase in the number of processing engines used in the average SOC from 2004 to 2016. The current forecast starts with 18 processing engines on an SOC in 2004, which jumps to 359 processing engines in the SOC for 2016. (Today, Tensilica’s customers incorporate an average of 6 processors per SOC and one customer, Cisco, has developed a networking chip with 188 active processors and four spares.)

I don’t think the ITRS Design TWG knows exactly what those 359 processing engines will be doing in the year 2016, but it estimates that these engines will consume about 30% of the SOC’s die area—roughly the same amount of area (as a percentage of the total die area) that’s consumed by last year’s 18 processing engines. In another decade, SOC designers will clearly get a lot more processing power for the silicon expended. Harnessing all that processing power is a topic for another blog post.

Parallelism is clearly the path to performance in the 21st century. Exploiting parallelism adheres to and exploits the true Moore’s Law, which is still very much alive, and veers away from the dying corollary of higher clock rate. Boosting parallelism, which is inherent in a large number of end applications, lowers the required clock rate and therefore lowers power dissipation. Given the thrust of processor and SOC design over the last decade, dropping the clock rate seems counterintuitive. Nevertheless, the physics demand it.

Moore’s Law continues to benefit all IC designers, even after 40 years, although it’s very handy corollaries seem to be dying out. With work and just a bit of luck, Moore’s Law will continue to benefit the industry for at least another decade.

(Thanks to Kevin Krewell, Editor-in-Chief of The Microprocessor Report, for nailing down the PC processor clock-rate facts so neatly in his recent editorial titled "AMD vs. Intel, Round IX.")

More on Moore

2005-04-19T09:30:00.000-07:00

Yesterday, I wrote about Moore’s Law and its 40th birthday. Well, today’s the actual day of the anniversary of Moore’s article in Electronics magazine and many people, including Gordon Moore, thought things might not get as far as they have. As recently as 1995, 30 years after writing that first article predicting exponential device growth in semiconductors, Moore said:

“As we go below 0.2 micron, the SIA road map says 0.18 micron line widths is the right number, we must use radiation of a wavelength that is absorbed by almost everything. Assuming more or less conventional optics, problems with depth of field, surface planarity and resist technology are formidable, to say nothing of the requirement that overlay accuracy must improve as fast as resolution if we are to really take maximum advantage of the finer lines.”

Moore delivered these words in 1995 to the members of SPIE, the International Society for Optical Engineering. Not very optimistic for the creator of Moore’s Law—and Moore went even further in describing his chart for lithographic progress:

“My plot goes only to the 0.18 micron generation, because I have no faith that simple extrapolation beyond that relates to reality.”

Getting even more serious, Moore said:

“Beyond this is really terra incognita, taking the term from the old maps. I have no idea what will happen beyond 0.18 microns.

In fact, I still have trouble believing we are going to be comfortable at 0.18 microns using conventional optical systems. Beyond this level, I do not see any way that conventional optics carries us any further. Of course, some of us said this about the one micron level. This time however, I think there are fundamental materials issues that will force a different direction.”

It didn’t happen the way Moore expected. Today, 180nm lithography is middle-of-the-road stuff and no one considers it miraculous while quarter-micron (250nm) lithography is trailing-edge and .35-micron technology—still in production—is absolutely Neolithic. Actually, even 130nm lithography is quite manufacturable today although it took a lot of engineering magic and ingenuity to “make it so.”

Even 90nm integrated circuits are already in production. In fact, the FPGA industry currently uses 90nm fabrication as its top-of-the-line technology foundation and 65nm chips are being fabricated, although no one would say that 65nm chips are yet in volume production. However, 65nm production in volume is clearly coming, of that there is no doubt. A couple of weeks ago, an article written by David Lammers in EE Times quoted Ted Vucuverich, senior vice president of advanced R&D at Cadence, as saying that the jump from 90nm to 65nm design rules might be quick indeed because the transition requires no change to the materials flow used in the current 90nm fabrication process so designers get the immense transistor bounty of the next design node without much of the pain normally associated with such a change.

Writing as a Regional Editor for EDN Magazine—way, way back in 1988—I described what was then the world’s smallest transistor: IBM had fabricated a transistor using 70nm design rules, which was an amazing feat in the disco decade. That 70nm transistor ran on 1V when nearly all digital ICs ran on 5V way back in 1988. Although the 70nm transistor required liquid-nitrogen cooling to combat thermal noise, the IBM researchers saw no fundamental reason why such tiny FETs couldn’t run at room temperature. Today we know they can. Quite well in fact. Back in 1989, leading-edge IC production technology used 0.7- or 0.8-micron (700 to 800nm) design rules. That was 10x what IBM had achieved in 1988 with its 70nm design rules and we are just starting to put such small transistors into production, some 17 years later.

So what is the smallest transistor made today? Just how far has Moore’s Law been stretched this early in the 21st century? In late 2003, NEC announced that it had built an FET with a 5nm gate length. Intel and AMD have publicly discussed fabrication of transistors with 10nm gate lengths and IBM built one with a 6nm gate length in 2002. (Note: For you purists, I know I’m mixing gate lengths and drawn geometries here for brevity’s sake. At the IEDM conference in 2002, AMD also discussed a flash memory that it built in conjunction with Stanford University using 5nm drawn geometries.)

These geometries are approximately 10x smaller than what’s used in today’s most advanced production devices. So, we already know that transistors will continue to work at geometries an order of magnitude smaller than what’s broadly manufacturable today and we already know ways to make such transistors. The ability to make such small transistors in production volumes will undoubtedly follow because the economic incentives to make things smaller and cheaper remain.

Even after 40 years, it looks like Moore’s Law still has a few birthdays left.

PS: How Moore’s Law got its name

Gordon Moore isn’t really the sort of guy to name a law after himself. He had help. Rick Merritt and Patrick Mannion told the story in an article in this week’s EE Times. It seems that it took another huge name in semiconductor lore, Carver Mead, to bestow the name. Mead started consulting for Moore back in Moore’s days at Fairchild and continued after Moore co-founded Intel. Mead named the law in an interview with a journalist in 1971. Mead was discussing his work on electron tunneling and the associated limits on device scalability. He spontaneously coined the catchy phrase during the interview. The rest is well-trodden history.

Happy birthday to Moore’s Law

2005-04-18T13:32:00.000-07:00

On its 40th birthday (tomorrow), Gordon Moore’s prediction about the increasing number of components that can be put on an integrated circuit is very much alive and well. However, it’s often cited corollaries relating to device speed and power dissipation, which are often confused with the law itself, are in big trouble. But I’ll leave that discussion for another time.

The August 19, 1965 issue of Electronics Magazine published the original article written by Gordon Moore, who was Director of Fairchild Semiconductor’s R&D laboratories at the time. Moore’s article titled “Cramming more components onto integrated circuits” predicted an exponential growth in the number of “components” (transistors, diodes, resistors, and capacitors) that would be built on an integrated circuit as semiconductor fabrication expertise grew. His initial observation was that the device-doubling time was 18 months, later refined to 2 years.

Incredibly, Moore synthesized this remarkably accurate, long-lived truism from very few data points. The integrated circuit had only been invented in late 1959, a little more than five years before Moore’s article appeared. By 1965, integrated-circuit fabrication technology had progressed only to the point where it could put 50 or 60 components on a chip. Moore conjured his doubling-trick projection using the five data points he had available. His law put the industry on a breakneck course that has lasted 45 years and will surely continue for at least another 10-15 years. However, the doubling time, now administered by the International Technology Roadmap for Semiconductors (ITRS), may be stretching out to three years as we approach the fundamental atomic limits of the materials. (Trace widths on today's most advanced ICs are now only a couple of dozen atoms wide and gate-oxide thicknesses are less than 10 atoms thick.)

Ten years after his first article appeared, Moore spoke about his law at the IEEE’s 1975 International Electron Devices Meeting (IEDM) and said that he saw “no present reason to expect a change in this trend.” However, over the years, there have been frequent predictions of the law’s demise.

For example, the industry was facing the transition from 3- and 2-micron lithographies to 1-micron technology in 1984. At that time, the fear was not that semiconductor fabrication technology would fail to keep pace. Rather, the issue was the IC designers’ ability to design such complex chips, which was falling behind the abilities of the manufacturing processes. Bob Kirk and Tom Daspit of American Microsystems published these paragraphs in their article “Making the Design Transition,” published in a 1984 issue of Semiconductor International magazine:

“The ability to design complex ‘one-micron design rule’ ICs is, in fact, a key in the semiconductor industry’s transition to using such processes effectively. … The capabilities of one micron technology will not be fully exploited until sufficiently powerful tools in these areas emerge.”

Remarkably similar to the situation the industry faces today with nanometer design rules, no? The 1984 article continues:

“Design engineers are, in fact, now beginning the transition from pencil-and-paper logic design to interactive design using engineering workstations. …

It should be noted that wider use of automated design aids is contingent on the acceptance of some reduction in the use of circuit area—known as area penalty. …

Automated tools generally waste some silicon area; they are not as area efficient as human designers.

While industry pressure exists to reduce area penalty, the sheer complexity of one-micron circuits dictates that some area be traded off in favor of completing designs in a timely way with automated tools. The pressure to reduce area penalty can be softened by trading off total design cost against the total manufacturing costs.”

So, the issues of moving IC hardware designers to higher abstraction levels and trading off silicon area for design complexity and cycle time have been with us for at least 20 years. Even 20 years ago, Moore’s-Law scaling was providing more components than could be accommodated by the design tools and methodologies in use. The same is true today even though designers have jumped several levels of abstraction from hand-drawn transistors, through schematic-drafting CAD systems, to HDLs and logic synthesis. Moore’s Law continues to keep the raw silicon capabilities ahead of our design abilities and will do so for at least another decade. After that, we will need to find another medium to work in because silicon will be worked out.

If it’s broke, fix it

2005-04-14T10:07:00.000-07:00

Bad news for SOC designers as reported in EETimes last week in an article written by David Lammers quoting Cadence’s Senior VP of R&D Ted Vucuverich. While the bulk of the article covered the industry trend toward adoption of 65nm design rules sooner rather than later (more on that topic in a later blog), the article’s last paragraph discussed the dismal state of SOC design success today:

"The industry has been weighed down by relatively poor first-time design success rates, he said, quoting data from analysis firm Collett and Associates. In 2003, only about one-third of the 130-micron designs achieved first-time success. After the third iteration, only 60 percent of the designs worked, he said, attributing hard-to-detect in the designs for the low rate of improvement. After three failures, many designs afflicted with "really hard problems" are declared disasters and abandoned altogether, he said."

A 66% initial failure rate is troubling and says something about the EDA industry’s current inability to support designs of deep-submicron complexity. Not to sound like a broken record here, but the current approach to system design, which is based on techniques developed more than 10 years ago, is now well and truly broken. The statistics prove it! This trend will only worsen as 90nm and then 65nm design rules become more common.

I believe that the solution to this design problem is to engineer systems at much higher abstraction levels. That means that engineers need to spend much less time hacking RTL, far less time verifying new blocks of custom logic, and much more time thinking about, tinkering with, and simulating systems at the block-diagram level. To do this, design teams must use building blocks larger than gates, flip-flops, registers, and ALUs. They must also cease and desist from manually translating algorithms from high-level languages into hardware-description languages.

Moore’s Law isn’t dead. The International Technology Roadmap for Semiconductors (ITRS) has codified this law and ensures that we will have more transistors per chip every year. Our system-design styles must now use those transistors far more effectively to overcome the barriers to complex system design and to substitute what’s in surplus (transistors) for what’s scarce (engineering time and project cycle time).

I work for a configurable microprocessor core vendor so it’s no secret that I think processor cores are part of the solution. They are pre-verified, correct-by-construction blocks of RTL that need relatively little verification. Processor cores can run software directly, eliminating manual translation of C or C++ to RTL. Configurable cores can run HLL programs at speeds approaching those of hand-built RTL blocks but they’re far easier to design into a system, in large numbers. Processor cores and memories are clearly part of the solution to the high failure rate of today’s SOC designs.

Don’t reinvent the wheel if you only need to add a few spokes

2005-04-13T13:53:00.000-07:00

Bob Colwell once worked for Intel as chief IA32 architect through the Pentium II, III, and 4 microprocessors. The guy knows a lot about traditional microprocessor design. These days, he’s a consultant and a regular columnist in the IEEE Computer Society’s publication Computer. The April issue of Computer just arrived at my house and Colwell’s column was the first thing I turned to, as usual because I love reading what he has to say.

This month, Colwell’s theme is the “point of highest leverage.” By that, he means putting your efforts on producing results that will have the greatest impact on your project. Some of his advice is excellent for any team contemplating the design of a new system.

Colwell starts by discussing a common sense approach to developing software:

“If you have written computer programs, you have probably wrestled with computer performance analysis. Naïve programmers may just link dozens of off-the-shelf data structures and algorithms together, while more experienced coders design their program with an eye toward the resulting speed. But either way, you end up running the program and wishing it was faster.”

This paragraph succinctly sums up the experience of all computer programmers for the last 60 years, ever since the switch was first thrown to power up ENIAC. Colwell continues:

“The first thing you do is get a run-time histogram of your code, which reveals that of the top 25 sections, one of them accounts for 72 percent of the overall runtime, while the rest are in the single digits… Do you a) notice that one of the single-digit routines is something you’d previously worried about and set out to rewrite it, or b) put everything else aside and figure out what to do about that 72 percent routine?”

Developers who choose alternative b) obviously understand the principle of the “point of highest leverage.” Previously, software developers stuck with fixed-ISA processors (like Colwell’s Pentiums) would have to heavily rework the troublesome code, perhaps dropping into assembly language to truly maximize the processor’s performance. Today’s SOC developers have another choice: extend a processor core’s instruction set specifically for the target code to achieve a project’s performance goals. This approach is a natural evolution of the harnessing of microprocessor technology, now that the tool automation is available to automatically generate the RTL for the extended microprocessor and all of the required software-development tools.

But things (at least processor-related things) are no longer the way Colwell describes them later in this column:

“It is, however, crucial to identify exactly what should be at the top of your worry list. Important changes (read: risks) such as new process technologies automatically go on that list because if trouble arises there, you have few viable alternatives. If you’re contemplating a new microarchitecture, that goes at the top of the list. After all, your team hasn’t conjured up the new microarchitecture yet—you’re only asserting that you need one. The gap between the two facts may turn out to be insurmountable.”

These words were sure and true in the day when processors and software tools were developed by hand. Developing new Pentium architectures is surely a year’s-long endeavor requiring hundreds of engineers. However, one engineer can now add new registers and instructions to a base processor in a few days using automated design tools. The resulting processor hardware, generated automatically by the design tools, is correct by construction.

There are two key elements that are essential to the ability to rapidly create such extended processors. The first is a small, fast base processor architecture that can execute any program because it is a complete processor. The base processor may not execute the target code at the desired speed, but it can at least execute that code. That’s a significantly advantageous starting point.

It’s also a very logical starting point. There’s no need to reinvent a way to add two 32-bit integers. It’s been done before. However, there are very real, performance-related reasons for adding new instructions that streamline code. For example, specific registers sized to an application’s data elements (such as 48-bit, 2-element audio vectors) and instructions that explicitly manipulate those data elements (such as direct codebook lookups and customized MAC instructions) can significantly boost code performance well beyond the limits of traditional assembly-language coding while adding very few gates to the processor’s hardware design.

The second essential element is the automatic generation of the associated software-development tools. The task of manually writing compilers, assemblers, debuggers, and profilers for a new processor architecture is as time consuming, and just as important, as developing the new processor itself. The processor is useless if software developers cannot easily write and debug programs for it.

Colwell’s column wavers perilously close to the edge of reality when he writes:

“Start with the givens. Experience gives you a set of things you can take for granted: techniques, know-how, who is good at what, tools that have proven themselves, validation plans and repositories, how to work within corporate planning processes. If you’ve accumulated enough experience, you’ve learned never to take anything for granted, but some things don’t need to appear at the top of your worry list.”

Most design teams do not have processor customization at the top of their worry list because they don’t realize that it’s now possible to directly attack processor performance by designing a better processor. These people already “know” that they’re not processor designers and that it “would be foolish” for them to even consider developing a processor with instructions specifically for a task on an SOC.

Conventional wisdom says that when a fixed-ISA processor cannot handle a job, you need to design hardware by writing some Verilog or VHDL. That conventional wisdom is based on nearly 35 years of design experience with microprocessors. When the microprocessor cannot do the job, it needs supplemental hardware.

That conventional wisdom is now plainly wrong. The “techniques” and “know-how” that Colwell takes for granted because of experience have now been superseded because of the march of technology. In the 1960s, the conventional wisdom rejected integrated circuits entirely. Here’s a quote from a speech Gordon Moore gave to SPIE in 1995:

“In 1965 the integrated circuit was only a few years old and in many cases was not well accepted. There was still a large contingent in the user community who wanted to design their own circuits and who considered the job of the semiconductor industry to be to supply them with transistors and diodes so they could get on with their jobs.”

Things were no different a few years later when Intel introduced the first microprocessor. The Intel 4004, which appeared in 1971, did not take the system-design world by storm. Design engineers knew how to wire up hundreds or thousands of TTL gates packaged a few at a time in 7400-series logic packages. They did not know how to write and debug software. Further, early microprocessors cost one or two hundred dollars, far more than the few TTL packages they replaced. As a result, it took about a decade for microprocessors to become well established as essential elements in system design.

Things were again no different in the late 1980s as the IC-design industry was facing a complete breakdown in design methodology. The schematic-capture methods of the day were proving to be completely inadequate to the task of describing the complexity of the chips that could be built. Here’s a quote from an article on VHDL written by EDA editor Michael C Markowitz in the March 30, 1989 issue of EDN Magazine:

“The reluctance of designers to embrace new techniques over their well-worn, time-proven methods will impede VHDL’s rate of acceptance… But once the benefits become clearer and the reluctance to write code rather than draw or capture a design dissipates, VHDL will gather steam as a design language.”

Markowitz was dead on regarding the onset of hardware-description languages although it was Verlilog, not VHDL that established a hold on designers in the United States. European designers did adopt VHDL.

Kurt Keutzer, then with AT&T Bell Labs and now a professor at UC Berkeley, summarized the situation quite well in his paper that same year, at the 1989 Design Automation Conference:

“One of the biggest obstacles to the acceptance of synthesis for ASIC design is the lack of education. Designing a circuit using a synthesis system is radically different from designing a circuit using most current design systems. The ability to hand optimize transistor or gate-level networks is of little use in synthesis systems, while an entirely new class of skills are demanded. The acceptance of synthesis procedures requires a significant re-education of designers currently in industry, as well as a broadened academic curriculum for the upcoming generation of designers.”

Today, there are many SOC designers who believe that things are as they always have been. They weren’t around 15 years ago to see logic synthesis take over the industry. They believe that people have been writing RTL since the dawn of time and will continue to do so until the universe expires of thermodynamic heat death. These people share much in common with the 1960s designers who wanted their discrete diodes and transistors, the 1970s designers who refused to learn how to program microprocessors, and the 1980s designers who clung to their schematics rather than embracing Verilog and VHDL. There are too many transistors on today’s SOCs to design even most of them using hardware-description languages. Once again, IC fabrication technology has outstripped our “popular” design methods and new methods are required to keep pace.

Colwell is right about a lot of things but he’s wrong about experience giving you “a set of things you can take for granted.” Thanks to the pace of technological development, you must always question your assumptions about the things you can take for granted. The industry changes. Design changes. And the companies that adapt quickly survive. The rest don’t.

Billions and Billions of Processors

2005-04-06T10:31:00.000-07:00

Last night, I attended an open house in Menlo Park at the new digs of the Foresight Institute, a nanotech think tank founded in 1986 to further the cause of nanotechnology. The Foresight Institute was created by K. Eric Drexler, who brought nanotechnology into the public light with his book, Engines of Creation, published in 1987. I remember reading Drexler’s book during a plane flight in the late 1980s. I also remember being stunned by the raw power and promise of nanotech. Today, nanotech still offers a lot of promise, and a few real products.

However, the image appearing on the Foresight Institute’s home page stopped me cold yesterday. It shows an artist’s conception of a desktop nanofactory building a white block about the size of a Rubik’s cube. The caption for the image mentions that the white block could contain, for example, one billion processors.

At Tensilica today, (and in our book Engineering the Complex SOC) we’re concerned with harnessing tens or hundreds of processors on an SOC. The average Tensilica customer uses 6 processors per chip and we have one client, Cisco, which has put close to 200 processors on one chip. That’s today.

A billion processors sort of approximate the processing power of all the computers currently attached to the Internet. In the volume of a baseball. That’s tomorrow.

We don’t yet know how to master the chaotic energy of a billion processors. However, the dreams of the people working in nanotechnology give us fair warning that we need to start thinking seriously about how to harness such complexity.

Evil Tech

2005-03-29T09:28:00.000-08:00

Designers don't always put their talents to good uses. Case in point: Gauri Nanda, a research associate at the MIT Media Lab and her invention, Clocky, an autonomous mobile alarm clock. When it's time to wake up, Clocky's buzzer goes off like any self-respecting alarm clock. However, to prevent you from hitting the snooze button, rolling over, and going back to sleep, Clocky jumps off your night table and hides, while still beeping incessantly.

Clocky is upholstered in shag carpeting so it looks a bit like a Duraflame firelog transformed into a brown Chia pet that's sprouted a pair of toy plastic wheels. The idea behind this evil invention is that by the time you locate and silence Clocky, you're no longer sleepy enough to fall back into bed for more shuteye. Clocky has enough microprocessor-based intelligence to find a different hidey hole each day so your morning wakeup ritual doesn't become too routine.

Here's to the MIT Media Lab, working on systems to make your life better in the 21st century.

Scrambled Flash

2005-03-28T17:05:00.000-08:00

I killed my Sony DVD R/RW drive last Friday. I had just downloaded and was applying a factory-supplied firmware upgrade that would turn my double-speed drive into a quad-speed demon. However, the Flash updater, running under Windows XP, died in the middle of the operation. (Windows crashed! What a surprise!) The result: scrambled Flash and a dead drive. A little Googling on the Internet established that the drive was most likely dead. Permanently. A help email to Sony is as yet unanswered so today, I replaced the drive with a Plextor PX-716A from Surplus Computers, which is conveniently located just down the street. Works like a champ, although the external drive box now looks funny, with Sony silkscreened on the top and Plextor silkscreened on the front.

The developers of the Sony drive who created a design that can be permanently disabled by an aborted Flash update need some remedial system-design training. An official download from the Sony support Web site applied by a reasonably competent operator (my engineering skills aren't all that decrepit) should not be able to destroy the drive. Yet that's what happened.

This episode holds an important lesson for all system designers: design for contingencies and expect Murphy to visit. The lesson is no less true for SOC designers as it is for board-level designers. Expect the unexpected and don't let the fates turn your design into junk.

Wizards of Greater Oz

2005-03-24T10:16:00.000-08:00

To my mind, Ray Bolger's role as the scarecrow in The Wizard of Oz stands out more than any other performance (even Judy Garland's). His song and dance rendition of "If I only had a brain" is a real high point in the movie for me. More to the point, the scarecrow, Dorothy, the Tin Man, and the Cowardly Lion all journey to Oz's Emerald City to ask The Wizard for things they think they need to complete their life (brain, way home, heart, and courage).

All of us in the high-tech industry are wizards of greater Oz. We labor to produce artifacts that we think will help complete the lives of the people on this planet (light, heat, food, transportation, entertainment, etc.). To do this, we've increasingly relied on processors, particularly microprocessors, to provide the "brains" of the electronic gadgets we develop. As the head of The Microprocessor Report, I and my colleagues often wrote about new and more "powerful" microprocessors that various companies developed to provide ever-increasing abilities to the new products of the tech industry.

The word "powerful" applied to even today's microprocessors is laughable. My cat's brain has more processing power than Intel's finest von Neumann machine and it doesn't need upwards of 100W to operate either. As an algorithmic-processing, image-recognizing, rule-generating device, the brains of most animals far outclass and outdistance today's simple silicon wonders.

What leads me to this topic today is Dean Takahashi's article in the March 24 San Jose Mercury News about a small company in Menlo Park run by former PDA gurus Jeff Hawkins and Donna Dubinski ("Numenta works to develop brain-like computing," requires free subscription). Hawkins has been funding brain research at the Redwood Neuroscience Institute in Menlo Park for several years and wrote a book last year titled On Intelligence detailing his theories on how the human brain works. Essentially, Hawkins believes that the brain works like a huge, deeply hierarchical memory. Each stage of the hierarchy is responsible for part of the decision making.

Hawkin's company Numenta intends to move these theories into practice. To that end, there's a software simulation already available. The products are in the future, to be harnessed by us Wizards.

EDA's Malaise

2005-03-23T16:44:00.000-08:00

EETimes' managing editor of design automation Richard Goering has just written an opinion piece decrying the problems in the EDA industry (see "Addressing EDA's malaise"). Richard does a good job of summarizing some big problems our industry faces:

... when you hear the word EDA, what comes to mind? Failed companies. Flat revenues. Endless lawsuits. Marketing hype. Depressed market values. Vision and excitement seem in short supply, and EDA's reputation among investors and customers is lukewarm at best.

and,

...the EDA industry has limited itself by focusing its efforts on digital ASIC and system-on-chip design — a discipline that is just one small part of the challenging job of getting products into customers' hands. At 90 nanometers and below, fewer and fewer companies are even going to try chip design. There aren't all that many custom-chip designers in the world. But there are legions of FPGA, pc-board and embedded-software developers out there, and they have requirements that remain unmet.

Richard then outlines what he sees as one way to address the problem:

The EDA industry needs to encompass more of the design flow and get out in front of a much larger group of users.

My esteemed colleague is absolutely correct. I am appalled at the conventional EDA industry's focus on synthesis and post-synthesis tools at the expense of system-level design tool development. Last year at a the first International SOC conference in Newport Beach, I asked a panel of representatives from EDA tool vendors if it bothered them that all of the SOC designs shown in the presentations made at the conference all had block diagrams that resembled the computer systems I'd designed 20 years ago. Didn't they think that system design had advanced more than that in two decades?

I got blank stares and the the reply, "Whay are you asking us that question?" Sort of highlights one of the EDA industry's problems, doesn't it? (By the way, EETime's editor Ron Wilson was there and he clearly heard me ask that question. Just look at the intro paragraphs in the article he wrote this week on on-chip interconnects.)

Here's Richard Goering's succinct summary of this issue from his opinion piece:

There hasn't really been a major methodology shift since the move to RTL in the early 1990s.

Yes, that's it in a nutshell. We've been designing the same systems at the same abstraction level for 15 years. In my opinion, based on the pace of development in the electronics industry over the past 60 years, that's about 5 years too long. We need a good revolution in design techniques every decade or so to keep the industry vital and we've been lucky enough to get that sort of evolutionary pace. Until now.

I believe what's needed, what's always happened to our industry in the past, is for designers to move up a level of abstraction. In the late 1960s, engineers stopped designing digital systems transistor by transistor and started using SSI and MSI integrated circuits. In the 1970s, custom ICs started to replace standard parts in high-volume products (such as calculators) and these chips were designed polygon by polygon on Calma systems. By the 1980s, digital-IC designers had moved up to gate-level design on Daisy, Mentor, and Valid CAD systems. In the 1990s, Verilog and VHDL, logic synthesis, and Synopsys became ascendant.

Today, designers are still developing RTL blocks by hand using Verilog and VHDL but the number of gates on the chips they're designing has increased by a couple of orders of magnitude. We're drowning in gates and we're smothering in verification! The low-level details of logic design are suffocating the industry.

What's needed is a new approach to system design that leaves lower-level block design to automated tools that create pre-verified, correct-by-construction RTL blocks. There just aren't enough engineers in the world (even with the legions in India and China) to manually design and verify all of the RTL today's nanometer SOCs can absorb. With the right synthesis tools, these same block-generating tools can crank out logic just as suitable for the big FPGAs with their acres of logic cells.

It's time to leave manual logic design behind and concentrate of new and interesting system architectures with truly high-performance abilities. As Richard Goering concludes:

Rather than just another tool, what's needed are solutions to broad-ranging problems.

I concur. What's needed is for the industry to break out of its narrow focus on RTL design and the straitjacket of the simple, antiquated system architectures of the 1980s and to develop 21st-century architectures that address today's application problems.

Red Herring Profiles Tensilica, Inc.

2005-03-23T08:36:00.000-08:00

Here at Tensilica, we’re thrilled that a publication as prestigious as The Red Herring chose to profile our company and CEO Chris Rowen in its March 21 issue. The 1-page article (plus a second page with a really big photo of Chris) does what it can to convey the arcane world of configurable, extensible processors and SOC design with limited space and much to say about the business of chip development in the 21st century. In the name of journalistic integrity and balance, the article quotes people who work at a couple of Tensilica’s competitors.

Unfortunately, our competition understandably doesn’t share the Herring’s journalistic sense of fair play and they used the opportunity to take some cheap shots. Imagine! Although Tensilica would never officially address the shortcomings of the competitors quoted by The Red Herring, through the wonder of the blogosphere and my personal blog it’s now a lot easier for me to return those underhanded volleys.

The Red Herring article quotes MIPS’ director of product strategy Tom Peterson. I’ve been on conference panels with Tom in the past and he’s a wily (as in cartoon character Wile E. Coyote) marketer. I really respect Tom’s ability to sling FUD; I think he’s one of the best. In the article, Tom is quoted as saying that “configurable cores are not as good a fit for products that run lots of software.” Now that’s just silly. The MIPS processors that Tom’s trying to flog are 32-bit RISC processors that can’t be configured.

Tensilica’s Xtensa processor cores are also 32-bit RISC processors. They can do everything a MIPS processor can do except run crusty old code compiled specifically for MIPS processors that can’t be updated because the original programmers have left or died off. Xtensa processors can also be configured so that they run specific target code faster…a lot faster. However, configuring and extending an Xtensa processor core doesn’t impair its ability to run any sort of software, but that’s just the impression Mr. Peterson would like to leave while he valiantly tries to distract the reader from realizing that MIPS cores are just too slow for most of the heavy lifting on today’s SOCs. Tom’s truly a wily guy. It’s too bad his processors are so big and slow.

Then the Herring article weighs in with a quote from Carl Schlachte, ARC International’s fifth CEO in four years. However, Mr. Schlachte’s approach to discussing the world of configurable processor cores closely resembles his many predecessor’s—he wraps a lie inside a truth sort of the way Tootsie Roll hides a soft chewy center inside a hard candy lollipop. Schlachte’s quote is: “We have been at this the longest. We can do it better than those guys.” It’s true that ARC’s had a configurable core longer than anyone. They developed a simple configurable processor core back when the company was called Argonaut Software, a video-game developer. That core was useful for developing new video games but the configuration tools were clearly never meant to be used outside of the company. Except for a few configuration options, any application-specific extensions made to an ARC core must be built by hand and manually verified.

Being first doesn’t mean being best. Tensilica has elevated automatic processor core extension to a fine art, especially with last year’s introduction of the XPRES Compiler, which automatically analyzes C or C++ code and then generates optimized processor extensions to accelerate the execution of that target code.

If you look at where Tensilica’s processors are being used in products today, you’ll see the target applications all require significant data processing: image and video compression/decompression, audio processing, and network packet processing. The Xtensa processor also runs operating systems and has displaced MIPS processors in that role. SOC developers see the Tensilica approach as a very fast way to develop the high-performance processing blocks they need for their SOC designs. On average, Tensilica’s customers put six processor cores on each of their SOC designs and some put a lot more (like a couple hundred). Tensilica isn’t so much competing with ARM, MIPS, or ARC as it is fundamentally changing the way SOCs are designed in the 21st century.

Clive "Bebop" Maxfield rides again

2005-03-21T09:18:00.000-08:00

As the Editor in Chief of EDN in the mid 1990s, I had the privilege of publishing some of Clive Maxfield's earlier writing under the bombastic title of Designus Maximus. It was an appropriate name for Clive's expansive personality. Clive has published several books over the years, which you can find on Amazon, but he started a new role today as a biweekly columnist for John Miklosz's SOC Central Web site. In this first column, Clive does a very respectable job of discussing how much SOC design has changed in just the last six years. We've gone from dipping our toes in deep-submicon design issues to neck deep, and the water's rising. All of these issues portend great changes in the way we'll be designing SOCs in the coming years.

Shoe Biz

2005-03-19T19:04:00.000-08:00

Adidas, the German shoe manufacturer, has just rolled out a $250 pair of athletic shoes with active cushioning, controlled by a microprocessor embedded inside the arch of each shoe. A magnetic sensor measures the impact in each step and the microprocessor adjusts a cable-tensioning system to add or remove cushioning as needed. The integral, replaceable battery lasts 100 hours, which is how long a top-line pair of running shoes like these Adidas-1 shoes is supposed to last anyway.

Compared to what?

2005-03-19T18:21:00.000-08:00

I think Jack Ganssle is one of the smartest guys in the world of embedded development. He’s certainly one of the best writers. Jack’s latest column at www.Embedded.com, titled “Software is Cheap,” reverses something he’s been saying for a long time. Previously, Jack’s often been known to say, “Software is the most expensive thing in the universe.” In his latest column, Jack writes software-development expert Tom DeMarco’s retort to that statement: “Compared with what?”

In this latest column, Jack’s backpedaling on his long-held view. He notes that software is expensive because of its incredible complexity. A standardized microprocessor core running a simple 7-line C program implements a bubble-sort algorithm that would take a substantial amount of hardware to replace. Jack, who tried to design the bubble sorter using only hardware and no CPU, writes:

“In an hour I managed a rough block diagram, one above the chip level (blocks have names like ‘adder’ and ‘16-bit latch’). But the sequencing logic is clearly pretty messy so I've just tossed in a PLD, assuming at some point it wouldn't be too hard to write the appropriate equations. And, yes, perhaps that breaks the no-programmable-logic rule, but to design and debug all that logic using gates in any reasonable amount of time is as unlikely as buck-a-gallon gas.

Translating the rough block diagram to a schematic might take a day. Then there's the time to design and produce a PCB, order and load parts (and change the design to deal with the unexpected but inevitable end-of-life issues), and then of course make the circuit work. We could be talking weeks of effort and a lot of money for the board, parts, and appropriate test equipment.

All this to replace seven little lines of code.”

I thoroughly agree with Jack. You don’t need software to replace simple functions (no one would develop a software-based UART any more, though we once did). However, using code running on processors is the right way to handle complex tasks, on a board or on a chip. Most algorithms start as programs written in C or C++ and then are either compiled for a target embedded processor or hand translated into Verilog or VHDL. Manual translation of complex algorithms increasingly seems like a fool's errand to me.

Here comes the IP rep

2005-03-19T18:08:00.000-08:00

EETimes reports that former Synopsys executive John Atwood is starting a company named The LogicWorks to serve as a "specialized sales channel partner" for smaller IP companies that do not have direct sales forces. I see this as another step in the normalization of IP for SOC design. Atwood's business looks a lot like the manufacturers’ reps (and these days, the big distributors) who sell ICs for the smaller IC companies that likewise can’t afford direct, worldwide sales teams.

Frankly, the controversy over IP use has always baffled me. Using IP blocks to simplify and accelerate SOC design seems no different to me than buying LSI chips to use in board-level designs. Someone else went to the trouble to design that IP. If the IP design is a good one (a thoroughly tested design with the proper documentation and a verification test bench), you’ll save time in designing your SOC. Poor quality IP designs are just like bad chips. They waste your time and money.

These days, time is precious. (Honestly, when was it not?) A missed market window incurs a huge expense. So do chip respins. Missed opportunites literally kill companies. Yet there are still pundits out there that decry IP as some sort of unproven concept. Sorry, I don’t get it.

And we're on the air...

2005-03-18T05:19:00.000-08:00

Hello and welcome to the blog dedicated to the art, science, and business of SOC design. In this blog, you'll find my take on the events and products that directly affect IC designers working on megagate digital and mixed-signal ICs.