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.

SE: Where does software fit into the overall SoC design flow these days?

Melling: What we’re hearing a lot of now is, ‘Our spec is this feature, and this feature includes software.’ It’s not just about a clock rate or latency. It needs to be able to run a certain workload with a certain power profile. The way customers are requesting the part they’re going to buy and the software they’re going to buy is being passed on as, ‘This is the requirement. If you’re going to sell to me, you’re going to meet this requirement.’ So now it’s an actual system-level requirement as opposed to hardware with these feeds and speeds.

Neifert: A lot of the concepts you’re introducing in virtual prototyping were first in emulation. Back then, it was always the hardware times that got the boxes and got the time on them, and if the software teams were lucky they got the midnight to 4 a.m. slots on the emulator because you had to sign up for time on there. When I go to my leading-edge customers now, there are always two people at each desk. There’s the hardware guy and the software guy, because they’re both looking at the same thing. The software guys have moved to the daylight hours.

Melling: And they’re presenting the use case for the hardware.

Karighattam: Those are the architectural decisions. They have contribution from the software guys, as well. Otherwise it would be all the hardware guys with power-aware scenarios. Some of those decisions can be made very early on in the architecture.

SE: The software guys have never done very well with the power utilization of the design, right?

Spotts: That’s correct, but they’ve never had the tools to do that.

SE: Agreed, but now that software is driving the hardware—and the other way around, of course—can the hardware guys respond to what the software needs better than the software guys could respond to the hardware needs?

Spotts: With a high-end system you’re writing an OS. What the OS does determines how much power is being used more than anything else. It’s not the person running the application. The question is whether power is going to be part of a virtual platform requires the interaction of the software debugger working with the models and being able to pull out different performance characteristics from the models themselves. Is that going to be a requirement going forward? Yes. Is it a requirement right now? It’s starting to become one. Are consumers really interested in power or are they interested in performance? It depends on the device.

Melling: People are technology geeks. Look at the whole jump to 64-bit phones. Was it a necessary horsepower upgrade?

Spotts: It was marketing. It took us by surprise that it was that fast.

De Schutter: Everybody always knew what x86 did. With a mobile phone, they didn’t. All of a sudden it became more of an issue that it had this processor and this feature. But going back to power, it’s important to see two pieces. One is power optimization. And there we are only at the beginning for how to use virtual prototyping for power optimization. It’s evolving. The other piece is the importance of software for driving power domains. That’s really important to have very early on to debug and try out in the context of a system. That piece has now become practicable. The other evolution is to have the software and hardware guys look at power very early on. There, the software guys are faced with something new where they also influence power. It’s definitely a new thing for them.

Neifert: Software guys have the biggest impact on power. A lot of people will talk about power as something that’s important, but few will do something about it in the virtual space. People have written white papers about it and it’s great fodder and interesting material, and some of our advanced customers are doing something about it. But it’s far from ubiquitous, and power is part of every discussion. I don’t want to have to plug in my phone every night.

Karighattam: If the new devices that we’ve been talking about become available, that’s where power is really important. There’s a lot of software, and that software really needs to be power-aware. Then people will start listening to you. There aren’t enough power models right now.

Melling: That’s an interesting area. So much of the power management is under the control of the software stack, and that software stack is an open-source software stack. How much can they differentiate using the same power control systems that everyone else is using? An SoC is a system that requires software to run alongside it, but for a big chunk of the software we’re saying no one is going to differentiate here. There are drivers and there is special stuff and there are GPUs. Everyone has their special IP, and they can differentiate on power of their pieces, but it’s harder to differentiate on power of the system.

Spotts: There’s all this talk about having an interface for power in the OS, so you can use the OS to control different parts of your system. How you implement that in hardware is up to you.

Melling: Yes, and that’s going to be what it takes to get it to the next level.

Spotts: It’s differentiation and using best practices for those interfaces.

Neifert: Once you start measuring things you can start making an impact on them. That’s the whole problem. If you don’t measure it, you never know.

De Schutter: And the question becomes whose responsibility is it? A mobile phone company sells a specific device. Even if you look at Android, there is a lot more flexibility. You can decide whether you want the accelerometer to be used in a game, and you have responsibility for when you turn these things one. If power is influenced by a game that has forgotten to turn off a key piece, is it the mobile phone’s responsibility, because it looks bad for the mobile phone? Is it the app’s responsibility? Is it the responsibility of the OS guys? The first piece is to put your software on a device and deliver a product. The second piece involves everyone else who is putting their products on there. It will be interesting to see if virtual prototyping will become one of those signoff criteria where you tested this, you passed this, you showed all the required power features when it’s not in use.

Melling: There will be a whole level of checks that come out of this. There will be debug , which are very detectable. You haven’t shut this off.

Spotts: You’re going to see more and more of that. Later versions of the OSes have more graphical features that make things smoother. They make text look a lot better because we have higher density screens. But these features tend to use more power. With the features that we have to reduce power, they tend to balance each other out. So we still have a phone that will last one day.

Melling: And I have thrown away an app because it drained the power. There will be some visibility even from the software level.

SE: Most of the code that’s been developed on virtual prototyping has been tied directly to the operation of the chip. Will we see applications taking advantage of it to get to market more quickly?

De Schutter: That depends on how you define a virtual prototype. There was some software developed to mimic certain types of devices, but it’s different than the EDA tools. It’s will shift somewhat, though, depending on what capabilities become available.

SE: Just so we’re all on the same page, what do we define as a virtual prototype?

Karighattam: It could be part of an SoC, a CPU-based subsystem, or an entire SoC. It could even be a bigger system. But here we are talking about an SoC.

De Schutter: To me it can be bigger than the SoC. In mobile, to some you’re defining it as an SoC. But in the industrial market, there may be multiple robot arms that have to interact with each other. That all has to be simulated in a virtual prototype. Now you also have the infotainment system that has to go through a hub to display things, so you have different interactions with multiple SoCs. That’s not the biggest use case yet. The biggest use case is still the SoC. But it’s changing. You’re starting to put more pieces together.

Karighattam: In the  space it could easily become all the sensors around the big device, but there are no models at this point to model all of these components—at least not at this point.

Neifert: One person’s system is another person’s subsystem. To me it’s a virtual prototype if it’s trying to model something that’s real. It’s not trying to abstract away the fact that there is actual hardware there. A virtual prototype has some portion that has a processor or processors, as opposed to saying this is a functional element. To what level that line gets drawn is fuzzy.

De Schutter: To me it’s a functional software representation. The electronic design needs to represent something so you can represent the functionality in software and the hardware. It could be just the apps processor or the modem, and then you might have both of them together, but it’s the software representation of something.