Five Questions: Simon Davidmann

Simon Davidmann, president and CEO of Imperas sat down with Semiconductor Engineering to discuss what software engineers want, software development challenges, software reuse, and software quality.

SE: What do software engineers want today?

Davidmann: We have a narrow view on it because we’re coming out of the EDA industry and we’re very close to the semiconductors and silicon. The bit that we’re aware of and focused on is those people that are developing software that is closely related to the hardware. That typically is affected greatly by the hardware — it isn’t too abstract away from it. We deal with people that are doing the OS porting, the drivers, around that sort of thing because they are building the semiconductors. What we see is that there are several different trends and themes going on, and some of it was actually very elegantly said by Aart de Geus a while ago at one of the conferences — it’s something that we’ve been thinking about for a while, which is around the way that software complexity is getting worse and worse. It’s increasing far faster than the number of people coming into this industry. The problem is this that exponential will, at some time, force a change in the way that people develop software. Today, they develop software the same way they’ve been doing it forever — with simple editors, etc. — and it has to change. It’s not easy to predict at this point what those changes are going to be but it’s sort of like in the old world, in the hardware world, people were building schematics and at some point you couldn’t build a big enough schematic. A million gates? You can’t do it, you have to change and there becomes a point where everybody fails to use the old methodology. The exponential and the complexity of software is meaning the old ways have to break — it might not be today, for this company or that company; it might not be tomorrow; but it’s inevitable as complexity is going to break it. That’s the first observation: the exponential is going to change the way that people do things. The second observation is that if something breaks, it can destroy the company that’s developing it. It might be something simple like a bug that you could update with software and it’s no big deal. But often these breaks can be, ‘Let’s recall 6 million cars;’ there’s a plane crash; there’s something that got sent off to Mars and it got mucked up — and it’s software related. It can be dramatic. We have much worse than just bugs in software; now we have this whole problem of vulnerabilities in security, and the threats because everything is an interconnected device in the IoT. What this means is you have to have better ways of doing things. What we’ve learnt in the design automation business is to do things in a more structured and controlled way, and I believe this is going to happen to software. One of the things that happened in the hardware world was the IP. Rather than verifying new designs, let’s load up pre-verified blocks, and I think that’s obviously going to happen with software. There are many people reusing software — whether it’s Linux or whatever — and I think that there’s got to be a whole focus on insuring that this is secure and not vulnerable to things.

SE: What are some of the biggest challenges that software engineers face today?

Davidmann: In the software world, it’s very hard to predict when things are finished. In the hardware world, you get a signoff, you get a schedule. In the software world, they really don’t measure things and control things in the same way. It’s interesting, when I first came across Coverity, I was very impressed with the way they did enterprise-wide visibility into the software development process. Imagine you can sit and watch how the software is evolving, the number of failures at check in were reducing, and things. We see with people using virtual platforms, they can do a much better job in terms of regression testing and continuous integration, where when you check something in it can be tested, which is what you do with hardware, but software guys don’t. What this means is that you can get a much better understanding of how your software is being developed, and the bugs that are detected and things like that. There are a lot of changes that have to happen to make the development process of software more controllable and predictable, but that’s assuming you’re developing all this software yourself.

SE: What about the notion of software reuse you mentioned?

Davidmann: One of the things that is not clear quite yet to everybody is that if someone is building a washing machine, they’ve got no clue about security or vulnerabilities. [With IoT devices], there are all these vulnerabilities and I think we’ve all got to realize that we can reuse software but we can’t expect your average programmer to understand any of this stuff about security or vulnerabilities. He’s used to programming a simple state machine on a door lock, or a refrigerator controller, or a microwave — and suddenly it’s all going to be internet connected, and suddenly it means there are all these vulnerabilties that they have never had to think about — they just included a block of WiFi in the design. You can buy the Raspberry Pi, or the creators from MIPS, and they have a processor, some other parts, and a WiFI block — and in no time at all, you’ve got a device with WiFi and you’re using it — but you haven’t touched it. When we’re coming to semiconductor IP, we say we can buy preverified blocks, where with software, we’re going to have to have blocks that we reuse, and I think a lot of that has to be almost pre-certified to be secure because what’s in that code? We have no idea.

SE: How can software with a higher level of confidence that it is of higher quality?

Davidmann: You need better tools than a traditional compiler and debugger. How did we check a silicon chip was going to work when we had schematics? We’d sit there and try to do the math, and in the end we came to logic simulators, etc. We’ve developed all these technologies to say, ‘ I know it sort of worked, but is it always going to work?’ We have to do this with software because too often people ask, ‘Does it run?’ Running once isn’t the issue, and especially as you go to multicore, sometimes it won’t work. The problem is that designers aren’t going to find these things so you need tools to help them, and provide a better way to do things. We say simulation is necessary but it’s not sufficient — it’s the beginning. To be able to use a virtual platform solution is the beginning of a new software development process, just like a gate level simulator was the beginning. So what can we do about this? We need better things: simulation, virtual platforms, regression testing, monitoring assertions, and measurement. I’m a great believer in testing the hell out of this stuff, checking it all you can, and then it will improve. Most people aren’t very good at programming so we need to give them more and more constrained stuff. If we’re providing the library that does some security thing, check that they’re using it properly.

SE: What is the measurement of quality in software?

Davidmann: People used to say it is the lines of code generated compared to the number of bugs, and things like that. I don’t think there’s a golden rule. I remember with semiconductors, people were looking at RTL design, trying to work out the efficiency of moving to RTL from gates: how many gates a day can I design? They wanted to know because that was their justification for the return on the investment to move in the methodology. But I think it depends on what you are doing. All different types of software will have different types of metrics. From my point of view inside my company, we measure the number of tests we have to the number of bugs on each of the platforms. In the embedded world it can be very different but it’s a matter of trying to track the process that you are doing — it’s not easy because how big is the software? Some people do it with the number of check ins. It’s trying to measure what they are putting in and how it goes backwards or forwards.