A new entry just showed up in the world of reverse debugging – Simulics, from German company Simulics. It does seem like the company and the tool are called the same. Simulics is a rather rare breed, the full-system-simulation-based reverse debugger. We have actually only seen a few these in history, with Simics being the primary example. Most reverse debuggers apply to user-level code and use various forms of OS call intercepts to create a reproducible run. Since the Simulics company clearly comes from the deeply embedded systems field, it makes sense to take the full-system approach since that makes it possible to debug code such as interrupt handlers.
I have also updated my history of commercial reverse debuggers to include Simulics.
The details available in the Simulics website and demo videos (1, 2) are rather scarce. Still, from what is visible some conclusions seem to be possible to draw:
- Debug is aimed at system-level code, including interrupt handlers and other low-level types of code.
- The solution is based on full-system simulation, using an ISS to simulate processor instructions and using functional simulation of processor peripherals. Simulics appear to have their own ISS framework, given the rather unusual set of processors supported (which makes it unlikely that it would be based on existing tools like Qemu).
- Reverse debugging is implemented fully, including running backwards to a breakpoint on code or data.
- Replay is fully deterministic for all (simulated) hardware events – which is necessary to achieve the above.
- Uses Eclipse and commercial IDEs (Microchip’s MPLabX) as the development environment, including relying on the reverse features in gdb (which we in the Simics team were part of adding back in gdb 7.0).
Looking at the materials, multicore is conspicuously absent. Thus, it would seem to be reasonable to assume that only single-core systems are supported right now. Given the technology base, doing multicore should be rather straightforward. It does complicate the GUI quite a bit, since you no longer have an easy single execution you can follow but need to allow for time on different processors, etc.
Value Proposition
The value proposition is the standard for reverse debuggers and full-system simulators. Scripting, automation, non-intrusive instrumentation, reverse debugging, better target insight.
They note that the speed of their simulators reaches into the 100s of MIPS, removing the “old limitation” of too-slow cycle-accurate simulators. Finally, it is worth noting that rather than building their own GUI, they make a point out of integrating with existing IDEs and debuggers with reverse support – basically relying on reverse gdb.
Nice Touches
As mentioned above, they have scripting and non-intrusive instrumentation of code.
As shown in the above picture, they have a nice timeline GUI element that they deploy inside of MPLabX or Eclipse. The timeline lets the user go back and forth in time by dragging a slider (from what it seems). The timeline supports zooming in on part of the execution, limiting the reverse debugging window to a subset of the execution. The run stops when it would leave the designated span of time. This is useful to do things like keeping the debug session limited to a particular task activation or function call invocation – avoiding the debugger just running away into the future or the past if you send if off into a direction where no breakpoint will hit. Neat.
Java?
<speculation and guesses follow>
It seems that the whole system is implemented in Java, which is quite a surprising choice for a full-system simulator. I have seen various university prototypes implemented in Java over the years, but never a fully formed solution.
It would seem natural to use C and assembler to build a maximum performance ISS, but I guess if you do a JIT compiler you could just as well do it in Java. How to call between JIT code and device models in Java is a good question – maybe you can somehow have the JVM help you do this in an efficient way? Would be interesting to learn more.
</speculation and guesses end>
Analysis
Technically, the tool as presented is a sensible idea (what else could I say, really?) The value of this type of debugger for deeply embedded code is clear. Anyone who have fought a race condition in task switcher or interrupt handlers crashing or corrupting global state is going to appreciate a reverse debugger.
What remains to be seen is if it is possible for Simulics to convince such users that their models are sufficiently complete and correct to be valid – for developers of small systems using small processors, my personal experience is that they are often very skeptical of models. Their code often unfortunately depends on low-level assumptions and behaviors such as precise hardware timing, which is a serious challenge for any kind of simulator.
The business model is also entirely opaque – who builds models, who owns models, what kind of cost this all works out to per user. Really, this is the make-or-break issue for all programming tools. Can you provide sufficient value to justify the price? And how do your customers look at price and value in this particular category of expense? Still, maybe this is the time – UndoDB also recently went on a PR and marketing spree, indicating renewed interest in the reverse debugger market.
One thought on “Simulics – A New Commercial Reverse Debugger”