DAC 2012 Gary Smith EDA Kickoff: EDA and ESL Growth and Four Different Software Virtual Prototypes

DAC 2012 kicked off yesterday with the annual DAC Reception followed by Gary Smith's keynote detailing challenges in EDA. For system-level design there was some really good news, but also some interesting detailed refinement on how much effort virtual prototyping for enablement of software development really takes.

Good news first. Gary put the 2011 EDA market in 2011 at $4,989M with a growth of 12% over 2010. Gary Smith EDA (GSEDA) remains optimistic for 2012, estimating the market to grow to $5,635M at a 12.9% rate. For electronic system-level design he put up the following chart:

Gary sees the ESL market as being in the knee of the hockey stick, having grown from $262M in 2010 to $460M in 2012 - that is a 75% growth year over year. He quoted Brian Bailey's prediction that we would enter ESL through verification and confirmed that most of the growth comes from advanced verification techniques including hardware/software verification.

Note that this is backwards looking data. Knowing GSEDA's methodology in which they query all vendors for last year's data, this is quite exciting for system-level design and verification and in very much in tune with my own "Energizer Bunny" reflection on how DAC 2012 will look like.

The other piece of Gary's talk dealt with the users of virtual prototypes. Gary called 2012 the year of the silicon virtual prototype, which is the one at which RTL is assembled and from which RTL implementation can commence from. Two silicon virtual prototypes were differentiated, the first one being the one at which design starts, hardware accelerators are added and transaction models are developed. It is the design of the in-house platform. The second silicon virtual prototype is the one in which existing RTL blocks are inserted, SystemC blocks are synthesized and the design is completed and verified. The output here is the golden RTL netlist. In previous discussions I had with Gary on this it has become clear to me - and I agree with the reasoning - that we better get this silicon virtual prototype adopted in mainstream as it is the basis and target for the next level - i.e. system-level design flows.

In parallel to the silicon virtual prototype driving hardware implementation, the software virtual prototype is enabling the software world and hardware/software architecture development. According to Gary the challenge is that there are actually four different virtual prototypes, serving four different users with four different specifications and four different price points:

1. The first software virtual prototype is the "Architect's Workbench" used by the architectural team for design formation and exploration and is usually modeled in C/C++ or M. At this level design teams select microprocessors and functions, the foundational platform for the design, together with some of the application platforms required.
2. The second software virtual prototype is the one on which application code is written.
3. The third virtual prototype is the one on which firmware is written. Application code is run on the software virtual prototype checking for latency and power.
4. Finally, the fourth virtual prototype is used by product marketing and sales to check out the design with prospective customers for possible modifications.

We see these use models from customers every day - I think they are correctly specified. We specifically see the separation between architecture and software/marketing enablement. The dilemma in the architecture world is that in order to make the right decisions, especially for processor selection and interconnect configuration, users often need - or at least request - a level of accuracy which is hard to replicate at the C/C++ or M level. For instance, ARMs AMBA Design or the interconnect configuration tools provided by Arteris and SONICS, have many configuration parameters and generate the RTL automatically. Performance validation but increasingly also more and more architecture decisions for interconnect are then made at the RT-Level.

The other question is whether the industry can afford four different virtual prototypes for enablement. All of these need to be modeled and - more importantly - verified. As I had stated many times in the past, this will only work if the virtual platform becomes part of the natural mainstream development flow, i.e. is not an afterthought to specifically enable software development or marketing and product definition interaction with the customer.

This remains a fascinating field and will for sure keep us occupied for a couple of DACs to come. The good news is that offerings like our System Development Suite and Virtual System Platform play right here in this market. We have at this DAC already 11 partners and customers publicly talking about their use models. You can find the details in my own "Energizer Bunny" overview of DAC 2012.

I am looking forward to seeing you in San Francisco!

Frank Schirrmeister