edagraffiti

Today’s guest is John Lambert. He is another Brit and is currently CEO of Virtutech (I was his VP marketing for a time). Prior to that he still has the scars from many years at Rational starting from the early days up until IBM acquired them, originally back in the UK and then over here. His blog was due to go out earlier but he has the modern equivalent of “the dog ate my homework."

His entry echoes some of the things that came up at last week’s DVcon panel, that IC design is only a part of the design problem.

Near death experiences

When, a few weeks ago, Paul asked me to write a blog entry, essentially to cover his rear end whilst he was gallivanting about in Mexico, I duly sat down and began to pen something suitably earnest on the future direction of EDA. Then, while twiddling my thumbs and staring out of the window hoping for some lightning bolt of inspiration to strike, I read a few of the earlier posts in order to get some more context. Fast concluding that in fact I had little new to say in that regard, I thought I’d do something different and instead focus more on the bigger picture. I’d construct a grand, sweeping, vision of how product development would look in the 22^nd century and what collectively we’d all need to do in order to get there.

It was all going swimmingly well until one Thursday night when my laptop tried to commit suicide by downloading a poisonous .Net update all by itself. Not sure why. Perhaps the whole futility of it all triggered some innate nihilistic tendencies buried deep within Windows Vista – because Lord knows they are in there somewhere, as any regular user of that abomination will readily testify – but whatever the reason, the net result (pun intended) was that by the time the PC was suitably detoxified I’d lost the thread of the epic story I was going to tell. Here instead, therefore, are a few basic points that I will make in the form of blank statements without bothering to justify any of my thinking. It’s just easier that way.

1. Follow the money. OEMs are in the business of building and selling things. Those things include chips and software, but that’s entirely incidental to the business they are actually in. The things they sell are either few in number and very expensive, or manifold and cheap, but either way those guys are the ones coining it, not the purveyors of the necessary picks and shovels. No use whining about it, that’s just the way life goes.
2. Complexity kills. Making stuff is hard, and getting harder. Everybody wants the things they buy to do more, be cheaper to buy, breakdown less and to be available sooner. Year-by-year, this makes the whole shooting match harder to manage regardless of volume, price or scale.
3. It’s good to talk. Building stuff has become multidisciplinary. Alas, we got here through rigid specialization. Stovepipes are good at keeping stuff contained, managed and concentrated (smoke, most typically) whereas what’s now most important are things like collaboration, iteration and exchange. This is a fundamental industry shift that is still only in its infancy. It’s important, OK?
4. Don’t sweat the small stuff. Why spend another $5m on upgrading your ASIC design tools when the end product, an ASIC presumably, accounts for only 20% of the hardware, the design and development of which consumes just 10% of the overall project budget? It makes no sense. Ditto buying a better compiler or smarter test tool. “Commoditization is murder”. Now there’s a slogan to live by. Or do I mean die by?
5. Complacency is death. So why on earth are all the EDA companies seemingly so stuck in their own stovepipe, refusing to strike out and fully embrace the broader product lifecycle? At least, that’s what you’d conclude from a number of the posts here, and indeed from looking at how intent they seem to have been over the past few years on getting better and better at serving the needs of a market slice that’s been getting smaller and smaller. Just how bad does the economic outlook for the industry have to be before one of the herd strikes out on their own to find greener grass way over yonder?

Someone, somewhere, soon will figure out that there’s room for one company to do for product America what the likes of IBM, HP and others have done for enterprise America, namely, to become the one partner that can pull together the deeply divided worlds of EDA, PLM and software, forging in the process a vendor with the breadth to truly breakdown those silos, thereby paving the way for the creation of new and innovative development processes. This HAL Corporation will supply both tools and techniques – process as well as product – that allow customers to systematically and repeatably shorten the overall end-to-end cost of designing, developing and delivering a new product. As a result, hundreds of man years of effort will be shaved from the total development bill, delivering results in timescales dramatically shorter than anything possible today.

All of this will happen because it has to happen. Market forces demand it, complexity dictates it. It just requires someone with the cojones to strike out, to make the first and boldest of moves.

Anyone want to lay bets on the most likely candidate to lead that charge?

Bottom-line: it’s time to welcome in the revolution; further polishing of the current stovepipes only results in shiner stoves, not warmer houses. I rest my case.

Today’s guest blog is from Grant Martin, Chief scientist at Tensilica. He worked for Burroughs in Scotland (in Cumbernauld, of all places, which makes Newark look attractive), Nortel in Canada, and then at Cadence before moving to Tensilica. He literally wrote the book on system design, most recently co-author of “ESL and System Design”. The British press used to have a rule that they would never mention another newspaper by name, but just say something like “in another newspaper.” Well, Grant has his own blog in another newspaper.

In some ways this a continuation of the power theme. Remember that it is much more power-effective to run a small processor at just the right slowish clock rate, than it is to run a powerful processor at huge clock rate for a short time and then idle it or shut it down while the rest of the system catches up.

Processor v hardware: the winner is…

 “Everyone” knows that processors are more flexible because they’re programmable, but “everyone” knows they are slower than dedicated hardware for high-performance algorithms.   But how do you decide between processor and hardware? There is a third way that lies between.

Although I do my best to ensure that designers I meet understand the idea of an   application-specific instruction set processor (ASIP), many people have never heard of them.   If they have, they may not realise that designers can configure them with automated tools.     And an ASIP is often so close to the performance, power consumption and area of dedicated hardware, that it is a superior option – especially with programmable flexibility.

Everyone is familiar with fixed general purpose processors, used for control tasks.   And fixed digital signal processors (DSPs) are found in many devices for data-intensive tasks – the ‘dataplane’. But what many don’t realise is how powerful the combination of configurable, extensible ASIP technology and dataplane tasks can be, compared to either a fixed processor or dedicated hardware.

Audio processing is an excellent example. An ASIP customised for audio, together with the right codec software, can decode MP3 running with a clockrate of just 5.7 MHz, producing near-CD quality sound and dissipating only 0.45 mW in TSMC’s 65nm LP process (details). Because this is a processor, other audio codecs can be downloaded to an audio player in the field long after it is sold.   Dedicated hardware could never provide this level of flexibility, and may not offer any significant advantage in performance, power or cost. Achieving 100+ hours of battery life on a portable audio appliance is more than possible with ASIPs.

Video is another dataplane application that can be mapped to ASIPs.   Standard definition decoding can be accomplished on a multiprocessor video subsystem running at 200 MHz in a TSMC 130 nm G process (details). And there are many other products, from baseband in wireless communications to high performance network processing, where you will find ASIPs.

ASIPs change the way in which system architecture is conceived. “Classical” hardware designers have a bias to implementing everything they can in dedicated hardware. “Classical” software developers have a bias to implementing all functions on general purpose processors – and running them at very high rates if necessary.   Running audio on a control processor at hundreds of MHz is possible, but hardly optimal. An ASIP-aware architect will instead use different tradeoffs. 

They will start by mapping control tasks to one or a cluster of control processors – in the latter case, possibly a cache-coherent “multicore” where processors can be powered down when not needed.   But every dataplane task is an opportunity to use ASIP technology.   Dedicated hardware blocks become a last resort – used by necessity, in order to meet system performance or energy consumption goals.   The result is a heterogeneous ASIP-dominated multiprocessor design where subsystems can be powered down whenever possible to minimise energy consumption.

Some recoil at the idea of sprinkling many processors in a design and “wasting” them when not needed. I remember the keypunch/card-reader/line-printer “cafeteria” line-up feeding the University of Waterloo’s mainframe. In that era, every computer cycle was indeed too precious to waste. 

But times change and the concerns of our youth give way to modern needs.   These days, every joule of energy is too precious to waste. Using ASIPs brings energy-efficient computation and communication to the exact places where they are needed. So the winner of “processor vs. hardware” is “neither” – but rather, the ASIP that lies in between.