Home > Community > Blogs > System Design and Verification > dac2012 gary smith eda kickoff eda and esl growth and four different software virtual prototypes
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

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

Comments(0)Filed under: System Design and Verification, embedded software, functional verification, DAC, Cadence, software virtual prototype, System Development Suite, Virtual System Platform, Design Automation Conference, System Modeling, DAC2012, GSEDA, Gary Smith EDA, ESL Market

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

 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.