Frank Schirrmeister From development of real-time software, through chip design and product management in EDA, I am excited to help drive system-level design over the chasm and to make it mainstream! Please also check out my monthly column 
Johannes Stahl has been working on system-level design methodologies and wireless design projects for 20+ years. As a marketing director at Synopsys he is responsible for algorithm design and high–level synthesis.
Marc Serughetti brings over 15 years of experience in embedded software covering simulation, IDE, compiler and debuggers as well as OS, middleware and application frameworks. He currently drives Synopsys virtual prototyping solutions.
Tom De Schutter has over 10 years experience in System-Level Solutions. At Synopsys he drives the customer processor design solution using Processor Designer, the TLM model library for architecture design and virtual prototyping solutions and the IP vendor relationships for System-Level Solutions.
Pat Sheridan has 25 years experience in the marketing and business development of high technology products. At Synopsys he drives the SoC architecture design solution using Platform Architect and serves as the Board member to the Open SystemC Initiative.Riding the Software Hockey Stick
Posted by Frank Schirrmeister on October 5th, 2009
Well, for those of you familiar with dancing, I am not talking here about the sequence in Rumba – albeit that’s fun too – but instead of being within a hockey stick adoption curve. How do you identify a trend clearly? You ask the same question multiple times and over time you will see the trend. That’s what we did with the following question: “What percentage of your total project effort is spent on software development (vs. hardware development) during design?”. We asked this question since March 2008 – at the Synopsys North American User Group meeting SNUG, then throughout the year during later user group meetings. We then asked again at DVCON 2009 in San Jose and finally at two recent events – the Virtual Multicore Conference and the EETimes Virtual SoC Conference (for which by the way you can still register and watch the archived presentations and our virtual booth).
The result is quite amazing to me and shown in an animated graphic on the left. Essentially, over this 18 month period the answer to this question shifted fundamentally. At SNUG 2008 84% of the users responded with either “0% to 25%” or “26% to 50%”. That means that for 84% the hardware effort was dominant. However, 46% already responded at that time that the software effort is between “26% and 50%”. I was quite happy with that response at the time.
Well, over the last 18 month the answer has shifted quite fundamentally. As the animation shows the numbers for software increased over the year. 15 month later, at the Virtual Multicore Conference, 61% of the respondents reported higher effort on the software side. And most recently, 18 month after we asked that question for the first time, at the EETimes Virtual SoC Conference 54% reported higher effort on the software side. That number is slightly down from the previous peak, but the audience was much more hardware oriented compared to the multicore conference.
So what does it all mean? Are we within the hockey stick transition to software taking over in importance in chip design? Perhaps. This is a good and relevant data point. And the impact on traditional hardware techniques may be even more profound, as I outlined in my Electronic Design column “When One Plus One Has To Be Less Than One”. Software becomes the means for verification, i.e. the software running on processors in the design becomes the actual testbench. The main advantage here is that the testbench can be re-used across different process steps:
- Verification can start using transaction-level models and virtual platforms even before RTL is available
- Once RTL is developed, the same testbenches can be re-used, now verifying the RTL in co-simulations of TLM models and RTL
- When the RTL is mapped to a FPGA prototype, the same testbench can still be re-used – both in pure FPGA hardware and in System Prototypes – hybrids of virtual platforms and FPGA prototypes.
- Even post silicon the same testbenches can be executed to test that that actual silicon is correct.
There are obvious differences in the amount of verifiable detail in each steps. Still, it looks like we have interesting times for verification ahead of us.
RSS
As they say there are statistics, statistics and damned lies. This falls in the latter camp I am afraid Frank. Unless you compare apples to apples, then there is no trend apart from the one that you want to make. You should have asked the question again at SNUG 2009 – then you would have had one data point that was useful, and I doubt that you would have seen much change.
The dominance of software has been in many products for years already, while for other it will probably never get there. There is no hockey stick about to happen because it already has happened.
Now on to you remark about using the software for verification. This can be very dangerous and I don’t have space to discuss all the details here, but if you have ever heard me talk about positive and negative verification then you will know what I am talking about. If you rely on software running as the only measure of success, then the hardware WILL stop working when you change the software.
Brian:
Thanks for your comments. You make a good point. For exactly that reason I was careful in pointing out in my pots “Are we within the hockey stick transition to software taking over in importance in chip design? Perhaps.”.
The datapoints of SNUG and the other worldwide SNUGS show a nice improvement in itself. They are definitely valid. The DVCON audience is similar to SNUG, hence it is the third valid datapoint. We will definitely ask the question at DVCON again next year in 2010.
On software for verification – I did not mean to suggest that software will be *the only* means for verification. However, while it won’t be “running as the only measure of success”, it will definitely part of the story. We have seen customers doing it already quite successfully.
Augh….my eyes! Get rid of the automated graphics on the blog home page. Instead, use a still pic and point to the automated graphics that will luanch on a separate page.
I really like the automation, after I clicked it open on a separate page. But too distracting as it is.
Looks like these data points are from quite different communities… in particular, anyone interested in multicore as a topic tends to be software-focused ayway. I agree with Brian Bailey. And I would also second just putting all the graphs side-by-side for ease of comparison.