Virtual Prototyping Takes Off

Semiconductor Engineering sat down to discuss virtual prototyping with Barry Spotts, senior core competency FAE for fabric and tools at ARM; Vasan Karighattam, senior director of architecture for SoC and SSW engineering at Open-Silicon; Tom De Schutter, senior product marketing manager for Virtualizer Solutions at Synopsys; Larry Melling, director of product management for the System Verification Group at Cadence; and Bill Neifert, chief technology officer at Carbon Design Systems. What follows are excerpts of that conversation. To view part one of this roundtable, click here; for part two, click here. 

SE: Is it just the core operational software that’s being developed on a virtual prototype, or is it the applications and other software? And can it be used to improve performance and energy efficiency?

Neifert: It depends a lot on the team. One person’s system is another person’s subsystem. Often you’ll see inside of companies where each team is optimizing their own subsystem independently. Typically it’s bare metal types of things, where they’re bringing multiple things together and running them together with a higher level of software so you can boot an entire system or portion of a system. But sometimes you’ll bring in the GPU and the model—all these things that have an impact on the overall performance. It’s a subsystem and then amalgamating these subsystems into a larger system. But it also depends on the company, because there is more maturity in some companies than others.

Spotts: And it depends on the type of system you’re building. If your creating a Cortex-M type system with sensors, you might be able to build the whole system and keep it cycle-approximate, run software and do more power analysis because it’s a small system. But you’re also going to have larger systems that are multi-cluster, multi-scalar. There is a need for people to run the full SoC for the system in an environment, whether that be emulation, virtual platform or some others.

Melling: I look at the app as the customer. If I’m producing a product, I deliver that to my customer. How that customer uses it is really the application interface to them.

SE: If you think about a database system, you’re really worried about the hardware and software working in perfect synchronization. In consumer, that may be different, right?

Melling: But if you look at database systems, there are entire ecosystems optimized around those solutions. Depending on what your job is and what you’re trying to do with the product you’re buying, then you have a view into the key interfaces you’re going to use to do that. And that’s where the application is. It’s really tough to say Angry Birds is an application but OpenGL isn’t. It’s pretty high-level software, but a lot of people wouldn’t consider OpenGL an app. But it’s an important app that’s delivered in some spaces.

Karighattam: But you have to know that scale is going to limit you in order to do something like this. You need to change your abstraction level in order to go to higher layers and model an app, rather than just doing your software or firmware. You need to make behavioral abstractions where you don’t have much content in the rest of the components—only then can you put large amounts of software in it.

SE: What you get out of that is just the basic functionality of that app?

Karighattam: Yes, with none of the details.

Spotts: There is a push, which isn’t quite there yet, which says that if you have enough performance with your virtual prototype then you can model some discrepancies as far as the causing the OS to lag. You’re at a high enough level to determine how long things should take from a software point of view. You can graphically see some of these problems ahead of time with a virtual prototype. It can amount to making changes in the hardware to take care of some of the artifacts that you see on an LCD screen.

SE: Are we getting to the point where even virtual prototyping isn’t running fast enough?

Melling: Yes. There are OS-level prototypes, too. There is an Android prototyping system and an iPhone prototyping system that is really an iOS prototype so that you can build your application. And it comes back to building your software, getting it up and running, and then validate against the real phone. But that still gives you a lot of functionality.

De Schutter: Pressure will always exist to speed things up. The IP companies are making things more difficult because customers want more. So it moved from single core to multi-core to multi-cluster. The more cores you put in a system, the harder it is. Everyone here is trying to figure out how to make things better. On the other hand, the alternatives suffer equally. If you put it on an FPGA or an emulator, you don’t get speed. So there is a tradeoff between what you can do, what’s the alternative. We’ll never get rid of doing final validation on real hardware. And on the performance and software side, doing relative measurements is also valuable. It was always the case where in virtual prototypes people wanted absolute numbers. They wanted to know how fast something would run and what would be the effect of changing something. Now, if people do something early on and they can see if it’s getting better or worse, they don’t know how much better or worse but at least they can steer their hardware or software in the right direction, both from a power and a performance point of view. That has a lot of benefits early on—more than doing it later in the cycle. After that you can validate the configurations you have, but you do get an advantage of using virtual prototypes for relative optimization.

Neifert: Speed is always a function of how much functionality you’re mapping into a design. A system that models an entire phone isn’t trying to model all the details, but it should functionally represent what happens in the operating system. You’re not going to boot that on the entire phone. It may be okay running something 10 layers up in the software stack, but if you go down a couple layers you need to talk to the physical hardware and it falls apart on there. It’s great for making approximate measurements and trends and not so much the absolutes. That’s fine. With power, users don’t need to know milliwatts or microwatts. They just need to know it’s taking X percent less than last time.

SE: We have a lot more IP in systems, and a lot of those are black boxes. Does that affect how we prototype software?

De Schutter: You can’t just deliver a piece of IP anymore by itself. You have to provide an infrastructure to enable IP developers to use that IP. That’s where IP virtual development comes into play. It’s the responsibility of the IP company to provide that visibility and create a model to optimize the software. Synopsys and ARM have done similar things with that.

SE: All the companies around this table have done that, but there are more companies providing IP than the big guys.

De Schutter: Design companies are starting to embrace this, as well.

Karighattam: Big companies have adopted it. The other companies need to adopt this now, as well. There are specifications for interfaces so people can show how a system behaves without providing too much detail on the proprietary nature of what they’re building. They don’t want to give away all the development secrets of their IP, but they could provide transaction-level, higher-level abstractions for how it works. You can use that to model a system much better than a black box. If every piece of IP is unknown, we don’t know what problems there are.

Neifert: When I talk to an IP company, it’s because a customer is telling me, ‘It would be nice if I knew what was going on in that model.’ That’s the impetus for working with them. We supply that to ARM and Cadence for accurate models of pieces of IP. People demand that. Often they want just the functionality, but sometimes they demand more. Sometimes you need to know what happened to a register and why did a bus hang. You only can find out when you get visibility inside a block.