David Stewart is founder and chief executive officer of Edinburgh-based CriticalBlue and has more than 20 years' experience in the EDA and semiconductor industries, 10 of which he spent at Cadence Design Systems, where he was a founder and business-development director of the SOC (system-on-chip)-design facility at the Alba Campus in Scotland.

This initiative attracted worldwide interest, and the design centre grew to more than 200 people in its first 18 months. Before joining Cadence, Stewart was a chip designer at LSI Logic, NEC Electronics, and National Semiconductor. He has served on the board of several technology start-ups and one venture-capital company.

What are the challenges that your customers are trying to deal with right now?

We straddle the hardware/software-development and -design boundaries, so we see customers on both sides. In a sense, there's one challenge right there, which has been identified for a number of years as a key issue in that hardware and software have typically been designed separately, and the two disciplines don't communicate well with each other. I don't think that problem has been solved yet, although it's better.

At a company level, what I see people challenged with is how to manage the necessary investment in building silicon platforms with getting the most out of those platforms. The biggest implication of that [challenge] is that these silicon platforms need to be a lot more programmable than they were before, so the increasing use of processors [is a concern], of course, but on top of that is layered the issue of power consumption, implying a smaller number of processing elements working together to deliver the same performance at lower power consumption.

So, you've basically got two interference patterns here: people trying to move toward more-programmable silicon platforms, but, on the other hand, they are also trying to deal with power consumption and how to continue to increase the performance of the platforms they are building but keep the power consumption under control. It seems like the only answer to that is to use more processors, so you've got more processors, but you've still got software problems. How do you program these things? It's not easy.

How well has the industry dealt with this problem?

I don't think we have dealt with it. In many cases, particularly with respect to the multicore programming, we have expected some new panacea to suddenly appear, and there is a group of people who have been waiting for that to happen, and there are other people that are getting on with doing things.

What history has taught me is that engineers tend to grow in an evolutionary way; they don't tend to suddenly throw something away and start at the beginning. So, a brand-new approach is an interesting idea, but I don't see anybody with much appetite for implementing anything like that at this point because, specifically, when the markets are tough and people are being cautious and the economy is not deft as it is at the moment, then people are much more likely to stick with what they know and try to evolve it than to throw everything away and make a huge bet on something that's brand new.

But will a new design be required in the future?

In an ideal world, that might be an interesting solution, but in terms of practically getting something that people might adopt, I struggle to find examples of where that's been done in the past. There aren't a lot of examples of brand-new things coming in and being adopted widespread across the industry; that's usually not what happens.

Even though people at various times say there are some hugely difficult problems that require a brand-new approach, it seems to me that engineers, being the kind of people [they] are, they find ways of stretching the envelope and making it work one last time.

It's similar to silicon nodes and how the industry would say, 'We'll never get beyond 150nm,' or 'We'll definitely not get beyond 90nm,' and now we're talking about 22nm. People say the laws of physics will break down, Moore's Law is going to die, and so forth, and, somehow, even though those things seem true at the time when people say it, engineers manage to find their way through it and reuse a lot of what's been done before and apply it to the next challenge. And I think that's what will probably happen in this case.

Are the multicore and hardware/software problems the same issues?

They are different issues. The issue of hardware/software design is when you are building a base platform and you are trying to decide what to put on it, how to configure it, which pieces to put in hardware and which to put in software, and so on, and there are a lot of challenges with that [issue].

Then, you've got the people who are actually using the platforms - the end customers, if you like - who plan to program them and use them. And they are not designing hardware; they are purely interested in getting the best performance out of the platform they've been given and needing to learn about multicore-software programming in order to do that. There is a connection, but they are two different challenges.

What does CriticalBlue focus on in the multicore and hardware/software areas?

In the hardware/software area, we developed a technology to allow the direct migration of software functionality into a hardware coprocessor. So, in other words, we developed a methodology that allows you to use software to design the hardware, which is something that doesn't really exist at this point. Usually, people make the decision up front and design a piece of hardware and a piece of software and stitch it together, but there are situations where you have something captured in software. You need to reduce the power consumption or increase the performance; therefore; you need to offload those functions into some kind of coprocessing element, and we've built a solution to enable people to do that.

In the multicore space, we've been doing a lot of work to help people analyse software that they have and figure out how to redeploy it on multicore architectures - for example, a single, standard RISC core and then multiple coprocessors. So, you might look at analysing some software running on an ARM processor and what you need to do to that software to be able to put it onto multiple coprocessors as well as the ARM.

What is CriticalBlue's approach to that issue?

We're focused very much on pragmatic solutions that help people work within the environments and the software codes that they already have, and it harks back to the point about whether we'll ever see a shiny new language in which everything can be captured and expressed. We may do, but we've certainly been working on the principle that we're going to stick with the existing languages and that people have a lot of existing software that they wish to be able to redeploy into these multicore architectures, and they need help with how to do that.

What motivated your interest in electronics?

I had an interest in electronics from a very early age, primarily because of the Apollo missions. I can remember being very fascinated with all the technology that took these guys to the moon. I think that was the original inspiration I had for wanting to design things and get involved with silicon chips.

By Ann Steffora Mutschler - EDN

See also: Electronics Weekly's focus on microprocessors, a roundup of content on microprocessor technologies and developments not related to the x86 architecture (from ARM, Texas Instruments and MIPS).

Sign-up for the ElectronicsWeekly.com newsletters
Daily Latest (Daily)	Weekly roundup (Weekly)	Mannerisms (Weekly)	Circuits (Fortnightly)	Made By Monkeys (Fortnightly)