“Never doubt that a small group of thoughtful, committed people can change the world. Indeed, it is the only thing that ever has.” – Margaret Mead
Imperas employs a grand total of ten people: eight Britons and two Americans. Yet the company is taking on an entire industry – indeed, an entire ethos and culture – and attempting to turn it on its head.
In short, Imperas thinks you’re doing it all wrong.
Writing software, that is. You’re doing it wrong. And you’re doing it badly. Your code is buggy, it’s not ready in time, it doesn’t do what you expected, and it costs a lot more to develop than you planned, and probably more than you’re aware. Speaking of which, do you even know how much you spent on code development for your current project?
That’s just sloppy. Imperas thinks that programmers, as a class and as a profession, could stand to learn a few hard lessons from their colleagues over on the hardware side of the house. Specifically, the SoC and ASIC designers. Now those guys have got their stuff together. You could learn a few things from them.
So what do the hardware guys do that the software people don’t? They simulate, mostly. They simulate the snot out of their SoC designs because it costs a million bucks if they get it wrong. And it delays the project by almost a year. And it generally costs a few engineers their jobs. So getting an SoC right the first time is an absolute imperative because, as Dr. Samuel Johnson observed, “When a man knows he is to be hanged in a fortnight, it concentrates his mind wonderfully.”
Thus, hardware design tends to be very formal and methodical. It’s structured. It’s testable. It’s simulated and modeled and verified out the wazoo. Code? Eh, not so much. Programmers tend to be of the ponytails-and-Birkenstocks variety, while hardware engineers hew closer to the Poindexter-with-eyeglasses-and-pocket-protector mold. Both disciplines are needed, obviously, but it sure would be nice if the code jockeys could produce more reliable, testable, verifiable software to go with that new SoC.
All well and good, but what is Imperas doing to make that happen? Glad you asked. The company provides models – lots and lots of models. The models are a key part (though not the only part) of a software-design methodology that Imperas believes can lead to better and more-reliable software. The company has models for more than 130 different CPUs, for example, including just about every different kind of ARM processor in existence, several generations of MIPS processors, the Synopsys/ARC architecture, Altera’s Nios, Xilinx’s MicroBlaze, the Renesas V850 family, and others. If you’re writing for any of those processors, Imperas should have you covered.
The idea is that you simulate your code running on a simulated processor with simulated peripherals and simulated APIs. Everything runs on a standard x86-based PC; the more CPU cores it has, the better. Imperas’s tools will translate your ARM, MIPS, or other binaries to x86 on the fly for simulation. As part of that translation, the tools also insert debug information so that you can watch your code and/or profile its performance. Since the entire thing is simulated anyway, the debug information doesn’t actually affect run-time performance at all. It’s the proverbial zero-footprint debugger. Whereas instrumenting or debugging real code running on real hardware will always insert some Schrödinger observability artifacts, simulated code doesn’t have that problem. Besides, debugging on real hardware requires… real hardware. Simulation lets the coders get started right away.
You can even swap out processor architectures midstream, if you’ve a mind to. There’s nothing to prevent your simulating your code on a MIPS processor one day and on a MicroBlaze CPU (or several) the next day. Want to see what effect upping the CPU core count would have? Go for it. Simulation means never having to wait for budget approval for new hardware.
For the programmer who doesn’t like to program, Imperas has bundled together complete kits of models and tools that simulate everything on several real-world boards. For example, you can get an ARM Versatile Express board-simulation kit, a Freescale Vybrid board complete with the MQX RTOS on it, a MIPS Malta board simulation, and others.
Are there downsides? Sure. For starters, simulation is slow by nature. Well, slower than real hardware, anyway. But speed counts only when you have real hardware to compare against. For teams who like to get a head start on their software, before the hardware is ready, simulation is about their only option. And, for what it’s worth, Imperas says its simulation is faster than everyone else’s. So there.
There’s also the dilemma of missing models. Yes, Imperas has hundreds of models for most any programmable device you could think of, but what about the other devices that aren’t modeled? Do you spend the time creating a model, or do you just skip it? Imperas has helped to define the Open Virtual Platform (OVP) standard that anyone can use to create reusable models, but, so far, the library of functions is limited to things that Imperas itself has created. Perhaps with a bit more time, there will be more third-party models, but today is not that day.
Then there’s the whole learning curve and tool-affinity thing. Developing code around models (or, at least, utilizing models as part of your development program) is new to a lot of coders. It’s alien. It’s foreign. It’s… almost hardware-like. For those prima donna coders who consider themselves artistes and above the quotidian concerns of schedules, budgets, and reliability, the whole Imperas methodology may rub them the wrong way.
For the ones who want to keep their jobs, however, it’s a good alternative to winging it.
Fixing bugs is almost too easy these days, and because of that there’s a tendency to ship the code now and promise to fix it later. Endless revisions are becoming a way of life. That’s an attitude that hardware developers can’t adopt; their stuff is too expensive. It’s only the programmers who can get away with endless tweaking – tweaking that’s done on the customers’ time, by the way. If what we need is solid code that’s correct before it leaves the factory, and not at some indeterminate time down the road, then software development will have to get a bit harder.
Leave a Reply
You must be logged in to post a comment.