Posted by Tom De Schutter on February 25, 2014
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, the software team comes into play for that specific design. While for many products this might be ok, but 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 like with many things, the saying “no pain – no gain”, is very true 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. While 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.
So where 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 6 snow plows can clear a highway, a well-orchestrated virtual prototyping methodology can remove any software roadblock.
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.