David Stewart is founder and chief executive officer of CriticalBlue (Edinburgh, Scotland) 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 center 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 special challenges do you face when working with customers and employees around the world?

Apart from all the usual challenges of managing time differences, the main issue is in keeping the company strategy and tactics aligned within the different geographies we operate in. In a start-up, things change very rapidly, and sometimes the changes can layer on top of each other such that you forget how much has and has not been communicated out to the field. This [lack of communication] can become an issue where small increments to strategy or positioning are made but not effectively communicated.

What advice would you give to other start-ups about the challenges of doing business globally?

I’d say expand into new markets one at a time. In other words, don’t try to do too much at once. Study your markets and see if they are ready yet. You may find that emerging markets—China or India, for example—are more appropriate for your products than the more traditional US and European markets. Finally, get someone on the ground who knows the local culture and activities; they will be invaluable.

What are the biggest 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 has 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 ... 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 ... 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 that [has] 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 ... 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.

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 upfront 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 analyze 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 analyzing 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.