DAC 2012: Handling a Double Paradigm Shift for Embedded Software Development

Change is hard. And we in product marketing for development tools are trying to cause change and find out if and how users are adopting new methodologies and tools. A little over a year ago, in the spirit of fellow Blogger Steve Leibson's law, that "it takes 10 years for any disruptive technology to become pervasive in the design community," I started to shyly formulate my own "Schirrmeister's Law" as "The ability to adopt a new design technology is inversely proportional to the number of changes it requires." Sounds simple enough but I have made my own mistakes here and see fellow product marketers doing it all the time. Of course the title of one of the partner presentations in the DAC2012 EDA360 theatre, called "Exploring a double paradigm shift for embedded software development" caught my attention.

The presentation was given by our System Realization Alliance partner, Methods2Business (M2B), and explored the areas of Virtual prototyping with our Virtual System Platform (VSP) as part of the System Development Suite plus formally proven model driven software generation using the tools provide by the company Verum.

M2B set up the challenge by usign data provided by Mindspeed's CEO and previously puplished in EDA360 Insider, stating that in modern System on Chip Design (SoC) for every 10 hardware design engineers project leaders need to account for 20 verification engineers (twice as many verification engineers as design engineers) and 200 software developers to write all the code executing on the processors in the SoC. That's 20 software developers for every hardware design engineer! So the key question becomes how we can deal with the escalating complexity of hardware and software design in less time and with higher product quality, especially when software and hardware are so interdependent but are still largely separate development efforts?

M2B then described the first paradigm shift in which software and hardware development can happen in a more parallel fashion with providing virtual prototypes based on transaction-level models to enable software development before the hardware is even available as RTL. The schedule graph they used was quite instructive and outlined very intuitively the effect of virtual prototyping.

Traditionally, software debug can only start when the FPGA is available, or the actual chip sample. Even though JTAG connections are well known, the capabilities of debug at that point is limited by the already finished hardware and the capabilities it provides. The immediate effects of virtual prototyping are shown in the middle portion of the figure. Software debug can simply start much earlier in the design cycle, before RTL and before hardware are available. The third portion of the figure shows the actual paradigm shift - the actual specification phase can be shortened, hardware and software implementation can start earlier, virtual platforms can serve as reference platform for verification and finally software debug can start earlier and better with full hardware/software debug.

To explain more detail how to build a virtual prototype, M2B explained the VSP TLM generation using a PL011 UART example, showed how to do transaction debug in VSP and how to integrated with the ARM Fats Models.

For the second paradigm shift, M2B called after outlining challenges how hardware and software implementation sometimes diverge, for better development solutions specifically on the software side, specifically to make software design verification a reality, to create zero-defect software systems, simplify dealing with complexity, deliver quality software in less time. Bottom line M2B called for methods to avoid bug-hunting in the first place, i.e. to avoid the need to hunt for bugs but instead provide tools that protect user against creating them.

That's where Verum comes in - providing software development automation with fully automated mathematical verification. The ASD:Suite provides model driven design to verify that all component designs are precise, correct, and complete before generating any code. It is combined with component based design - with and interface and a design model - for scalability.  The application guides developers through an iterative process of creating and editing models to ensure that specifications are complete and all execution scenarios are covered.

In an ASD model a sequence based specification is created using regular expression and Mealy machines, and from it both a formal model and source code in various languages from MISRA C to C++, C# and Java can be created for various platforms like Windows and Android. The generated formal model contains communicating sequential processes (Hoare and Roscoe) and allows process algebra and finite state model checking to ensure formal correctness. The claim is that with using formal techniques the thinking shifts to the requirements, architecture and design, coding becomes a lot less but starts later and creates bug free software with almost no maintenance.

This is very much in sync with a presentation I delivered at EDPS, in which I suggested that System Modeling is a next abstraction level we are working towards. The model-drien design entry Verum suggests would be such a system-model, of course there are others as already provided by The Mathworks or other with oferings for UML and SysUML. I had seen a similar presentation from M2B at CDNLive! in Europe before, and they also showed a Space Invador Game atomatically created and formally verified, executing on a ARM based virtual platform. Quite entertaining!

Adoption wil be the difficult issue as design teams are naturally resisting change. As stated earlier, the ability to adopt a new design technology is inversely proportional to the number of changes it requires, and making both the adoption of virtual prototyping and the use of formal techniques work at the same time, will be a challenge. It will require an ecosystem of providers like our partners M2B, who offer implementation and consulting, to help guide project teams through methodology changes as they are adopting new methodologies.

Frank Schirrmeister