Clearing Software Roadblocks

Last week I was traveling across North America visiting customers. Besides being amazed at how cold it is in the rest of North America (I live in Silicon Valley where the sun has barely left us during the entire winter), it was good to talk to a wide variety of companies and discuss their software development needs. We encountered three types of companies considering the use of virtual prototyping to pull in their software development schedule:

Type 1: Companies that have used virtual prototypes in the past, or other groups inside the company have used virtual prototypes and are preparing for their next design to deploy a virtual prototype to start their software development effort before hardware availability. At these companies virtual prototypes have become the norm to meet the SoC delivery schedule.

Type 2: Companies looking for a point solution to pull in one specific aspect of their software development effort. The overall software stack might not be too complex to require a virtual prototype to start early and benefit from the extra control and visibility, but for certain tasks, typically device driver development, OS porting or boot code bring up, virtual prototypes provide an instant ROI. Especially with pre-constructed virtual prototype packages that contain a reference design using their target architecture e.g. ARMv7 or ARMv8, and interface IP e.g. DesignWare USB 3.0 or DesignWare Ethernet, the software team is up and running quickly and can develop the specific software much faster than with any alternative software development solution.

Type 3: Companies where things are starting to break. When I bring up my slide highlighting the value of shifting left, namely pulling in the software development task alongside the hardware development, there is an “aha” moment. These companies recognize themselves in the “before virtual prototyping” setup: full serial development where all focus first goes to the hardware bring-up, and only once the hardware is ready does the software team comes into play for that specific design. While for many products this might be okay, for a lot of other applications there comes a point at which this methodology causes issues: e.g. late time-to-market, poor alignment of hardware and software or poor software quality due to increased software complexity and tight development schedules. This is where companies can benefit significantly by adopting virtual prototypes. But as with many things, the saying “no pain, no gain” is very apt in this situation. As one of the key engineers stated during my recent visit, “Even if we had a virtual prototype today, there wouldn’t be anyone available to use it as all software developers are still working on the previous design.”

So how do you turn serial hardware/software development into parallel hardware/software development? In a lot of cases it requires a top down mandate. Only through tight coordination and planning and moving resources to fit the new methodology will virtual prototyping truly provide its full benefits. You can only achieve a game changer experience if you are willing to … change the game.

As I encountered a lot of snow during my trip across North America, it is also interesting to see the perception of snow as a problem or not. In Texas snow is so uncommon that there just isn’t material available to deal with it. In Minnesota snow is just a fact of life during the winter. See the impressive picture below of a series of snow plows clearing the snow in Minnesota’s Twin Cities.

While for some the software content is not big or complex enough to need a lot of attention, others require a targeted solution for a targeted problem (comparing a single snow plow to an out-of-the-box virtual prototype for device driver development). And for many others the software complexity has just become a part of their product delivery and scheduling and through tight coordination and the right tools, they learned how to deal with the complexity. If six snowplows can clear a highway, a well-orchestrated virtual prototyping methodology can remove any software roadblock.