HOME    COMMUNITY    BLOGS & FORUMS    A View from the Top: A System-Level Blog
A View from the Top: A System-Level Blog
  • About

    A View From The Top is a Blog dedicated to System-Level Design and Embedded Software.
  • About the Author

    Tom De Schutter
    Tom De Schutter is responsible for driving the virtual 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.

    Achim Nohl
    Achim Nohl is a solution architect at Synopsys, responsible for virtual prototypes in the context of software development and verification. Achim holds a diploma degree in Electrical Engineering from the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany. Before joining Synopsys, Achim has been working in various engineering and marketing roles for LISATek and CoWare. Achim also writes the blog Virtual Prototyping Tales on Embedded.com.

Clearing Your Software Roadblocks

Posted by Tom De Schutter on February 25th, 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.

 

Share and Enjoy:
  • del.icio.us
  • Digg
  • Facebook
  • Google Bookmarks
  • Print
  • Twitter
  • StumbleUpon
  • LinkedIn
  • RSS