UltraSoC: Addressing their Customer’s Customer

UltraSoC is on a roll, having just wrapped up an energetic participation in the last month’s RISC-V conference in Shanghai, where UltraSoC CTO Gadge Panesar was a speaker. Additionally, the company is announcing “new funding, new investors, and new board members” – including UC Berkeley’s Alberto Sangiovanni-Vincentelli.

When I spoke this week with company CEO Rupert Baines, he started with Shanghai: “There is so much interest in RISC-V in China. The attendance there [exceeded] the headcount at the previous meetings at Google and MIT, although the numbers may be confusing as there were so many students at the Shanghai event.”

Asked if the RISC-V event would be in China again, Baines said, “I believe going forward there will be one conference in the U.S. each year, probably in Silicon Valley, and one international. Nvidia sponsored the latest one through their presence in Shanghai.”

Turning to UltraSoC, I asked about the company’s origin, market and competition.

Baines said, “We do semiconductor IP that solves a problem. The chips are so big and complicated today, understanding how they work – with lots of processors and lots of software interacting with each other and the real world – is incredibly difficult.

“You’ve got architects doing the best they can, verification engineers giving their best effort to see that it all works. But knitted together, it’s really different [than just looking at the various pieces].”

That is where UltraSoC comes in, per Baines: “You design our IP into your design, and it tells you at a rich, meaningful level what the processor is doing, and what the transactions are doing over a vast [range of activity].

“It’s a step-up from a wire trace or signal, because it’s also looking at transactions and protocols. It tells you that this bit of software has traveled that far and with these impacts.”

“We have several different ways that people use our IP,” Baines continued. “They use it for debug in the lab.

“And also, when the system [under consideration] doesn’t work quite as well as you would expect, our IP helps you look at things and say, for instance: Hang on, you can get a lot more information through here.

“Or, this unit is supposed to be asleep at this point [in a transaction] but it’s not, so you can reduce power by making sure that unit is asleep.

“Our IP finds these kinds of power reductions, optimizations, and performance improvements – importantly, without changing the silicon.”

“It sounds like you’re offering the silver bullet that many people have been looking for by way of system verification,” I noted.

Baines chuckled, “Not quite a silver bullet, but our IP certainly helps.”

“Still, it seems to address the huge conundrum,” I said. “There’s no guarantee third-party IP will function properly within the unknown environment of the design into which it’s dropped”

“Yes,” Baines replied, “IP in isolation and software in isolation [may be proven], but together there can be dependencies and interactions. The individual units may be great and pass their tests perfectly, but when you stitch it all together, problems develop and the finger-pointing begins.”

Baines offered a real-world example: “We know of a DSP [that was under development] where everything in the design was great. But then there was a high-level software upgrade in the DSP and the whole thing crashed.

“The designers did a regression test, and found that in previous versions of the software everything was fine. But when they made one improvement, made one change in the new version, two different ‘things’ accessed the memory at the same time, which caused a back log and back pressure, which meant something went wrong with the time dependency.

“The crash wasn’t really anyone’s fault, because each unit worked beautifully. But there was a subtle interaction between two slightly different things [which produced the failure].

“This is a situation where, if they had built our IP into their system, we could have solved the problem and saved them three months of effort and heaven knows how much money.”

“What is the source of your admirable technology,” I asked.

Baines said, “It was spun out of a couple of universities, motivated by the automotive market and sponsored by research at Kent and Essex several years ago. It was that research that lead to our technology, and caused the company to be founded in 2009.”

“I joined the company as CEO two years ago,” he added, “to change the mindset from a university spin-out to a commercial [enterprise], and we’re now going great guns.

“We have fantastic reference customers – companies like HiSilicon, Movidius, Imagination – and a lot more under NEA.”

“Sounds like there will be quite a queue at your booth at DAC,” I suggested.

“Who knows,” Baines replied, laughing.

“We had a lot of interest when we exhibited at Embedded World in Germany – that huge, sprawling show. And the response we had at ARM TechCon was quite amazing.”

“And speaking of ARM,” Baines added, “you asked about our competitors.

Well, ARM has a product that could be seen as a competitor, but for two different reasons it is not. First, it’s very processor center, really focused on the CPU, where we look at the system as a whole.

“And also, their product only supports ARM processors because they want to sell you their chips. We are vendor neutral, however. We support MIPS, CEVA, Tensilica, and RISC-V.

“In fact, we did demos of RISC-V at a recent ARM TechCon event.”

“Wow,” I said. “Did ARM know that?”

“Yeah,” Baines said. “We had hoped they would throw us out – it would have generated so much attention for us.

“But instead, we got a queue of ARM people all wanting to see our demo, excited to hear about it. [In reality], although we compete with ARM in some areas, we actually cooperate with them in others.”

“Okay,” I said, “give me the elevator pitch for your announcements for DAC in Austin.”

Baines complied: “RISC-V is elegant and open source, and it’s getting a lot of traction, but it’s not a complete solution.

“Even though there’s an ecosystem developing around the core instruction set, one of the areas people say is missing in RISC-V is debug. Various people, including ourselves, are addressing this.

“Using our IP, you get an instruction trace that tells you what the CPU is doing and how performance may be lacking.

“We have developed a specification for the processor trace, and have now contributed that to the RISC-Foundation, which is looking at it and studying it. They may decide to adopt it [unchanged] or decide to adopt a derivative.

“For us, it’s good either way – although we have contributed something that we believe is a pretty complete design. We believe our block will be a good one, and will [allow for] commercial implementations within the RISC-V world.

“Following the open-source specification, anyone can use it and work from there. We have developed a product that follows that specification that we will license as a commercial block, but we are happy to have competition [in this area].”

“It looks like this RISC-V thing is catching on like wild-fire worldwide,” I commented.

Baines agreed: “I’ve never seen anything like this.

“Yes, there have been other open source software projects, but they have been much longer [in being adopted]. Although Linux is now dominant, for example, it took quite a long time to catch one.”

“There are lots of different reasons why people are so interested in RISC-V,” Baines added.

“First of all, some people are just looking for something cheaper. That [motivation] is very straightforward.

“Second, some want an element of control. You can buy an architecture license from ARM, but it’s expensive and comes with constraints. When you do something with RISC-V, however, you completely customize the architecture yourself.

“Third, there are all manners of different commercial and technical motivation, which is why it is getting so much traction.”

“Would UltraSoC be where it is today without the RISC-V movement?” I asked.

“RISC-V is opening doors for us,” Baines responded, “but everything we have done to date is based on the value of our technology in general, and its application to an existing set of processors.

“RISC-V wouldn’t have made any difference to us up to now, but going forward it does mean increased growth for us.

“Overall, however,” Baines concluded, “we are a growing business, ventured-funded, and have really, really good technology investors.

“Professor Sangiovanni-Vincentelli is a big advocate of what we are doing, which is why he is now a senior advisor for our lead investor. And given the $6.4 million proceeds of our most recent funding, we are going to ramp up even further.

“We license our IP to the people who make the chips – companies like Microsemi – and those people really like what we’ve got. They can license it from us for a fraction of what it would cost for them to develop internally.

“They might have some legacy in-house capability, but usually what we do for them is better. And they can assign their engineers to something that is unique and adds value to their products, rather than have them do something we already do well.

“And then, we get a lot of love from the system companies, the people who are building the products that use the chips. We are building our presence with these companies.

“They know they can’t control the silicon, but they can make their system-level software and product-level designs better with chips they’ve bought from our customers – chips that have been improved using our IP.

“Yes, we get a lot of love from our customers’ customers, because system complexity is the problem we solve.”

***************

Tags: Alberto Sangiovanni-Vincentelli, ARM, ARM TechCon, CEVA, Design Automation Conference 2017, Gadge Panesar, HiSilicon, Imagination, Microsemi, MIPS, Movidius, RISC-V, Rupert Baines, Tensilica, UltraSoC

This entry was posted on Thursday, June 15th, 2017 at 8:27 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.