Home > Community > Blogs > Functional Verification > dvcon 09 saas panel thoughts part 3
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Functional 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: *

DVCon '09 SaaS Panel Thoughts, Part 3

Comments(2)Filed under: Functional Verification, DVcon, SaaS, Xuropa, Harry The ASIC Guy

In my previous posts on the DVCon 2009 panel on Software As A Service, or "SaaS" as it applies to EDA, recall that the main issues that came up were:

  • Security (the focus of Part 2 of this series)
  • EDA applications that can clearly benefit from SaaS
  • Bandwidth needs
  • Configuration control
  • Dealing with and/or migrating legacy flows & data


Having addressed the security issue in my last post and/or putting security aside for the moment, the second question on the list is really the most critical one to answer.  Here goes ...


First, please allow me to avoid rehashing SaaS-related economic analyses.  There are plenty of online sources for people to explore the raw nuts & bolts economics of the "make vs. buy", "build a local data center & buy licenses vs. SaaS" decision.  Let's assume for now that the economics are at least be a wash, and instead let's focus strictly on potential benefits that could be experienced by the upper most application layer, i.e. the very tippy top of the stack where end-users interact with the EDA tools themselves.  When you "look down" from the end-users perspective, the following EDA applications come to mind:

Coverage and Metric Driven Verification
As any practitioner of Coverage & Metric driven verification will tell you, the number and rate of bugs found has a strong correlation with the number of simulations and metrics you track.  Rephrasing for the uninitiated: this means that the more unique tests that you can run in parallel on a device under test (DUT), the more bugs you will find.  In fact, the customers that have the largest compute farms (more than 1,000 CPUs), actually have the problem of finding more bugs than they can handle -- which is a far better problem to have than paying for the direct and opportunity cost of a chip "re-spin" (FYI, these days re-spin costs are commonly greater than $10MM even without factoring in lost revenue from being late to market, etc.)

Unfortunately, most EDA setups have far less than 1,000 CPUs to work with, so their bug discovery rate will be proportionately lower, and/or their risk of a "bug escape" will be higher (i.e. a bug that appears in a finished product that makes customers, or customers' customers lives very painful).  The point w.r.t. to SaaS is that in theory anyone could have on-demand access to as many CPUs as they were willing to pay for, hence they could predictably scale their bug discovery rate.  Thus, early on in a verification project, when both the testbench and DUT are immature and bugs are pretty basic and easy to find, a relatively small number of CPUs could be employed.  As the project matures, and the bugs become harder and harder to find as the tape out date approaches, the verification project could ramp up to use 1,000s -- even 100,000s -- of CPUs to get the most out of a metric-driven verification approach. 

(Think this is a crazy notion?  There are customers today that run well over 100,000 simulations on their internal cloud networks 24/7, for the purpose of metric-driven verification of their chips.)


Any other application of running jobs in parallel
Beyond the verification space, the EDA world has a variety of applications that offer significantly higher wall clock performance, greater quality of results, or both, when multiple jobs are run in parallel.  Applications like simulation of pure analog circuits,  routing printed circuit boards, and multiple "what if" synthesis runs are but three that come to my mind -- I'm sure the gentle reader can think of others.  The point is that all these applications demonstrably benefit from access to more CPUs, hence can benefit from on-demand access to a big fat cloud of compute resources.


EDA tool evaluations
Yes, you read the title right -- EDA tool evaluations, at least the initial discovery phase, can be enhanced by cloud computing in a unique way.  Specifically, recall that my colleagues on the Cadence VIP Team have our whole MIPI Verification IP product available to try out now in the Xuropa Online Lab (For example, here is the link to the MIPI "DSI" lab)

The key thing to appreciate is that the Lab is hosting the real product for people to run and interact with live, vs. some FLASH demo or AE video.  (Brief digression: given cloud computing and SaaS has been at the heart of their business model, as you might expect the Xuropa team has some great articles on SaaS w.r.t. to EDA.  If I haven't worn you out on this topic, I recommend you checkout their articles too -- start here.)

Another take on this particular SaaS+EDA application is just how "non-traditional" it is, i.e. my ideas above of using the cloud to "run a lot of stuff in parallel" isn't a big stretch from standard EDA practice.  But when you see an intriguing application like Xuropa, one can't help but wonder what other applications people will start dreaming up to leverage the properties of cloud computing.


Finally, what about the last 3 items on the main issues list?

  • Bandwidth needs
  • Configuration control
  • Dealing with and/or migrating legacy flows & data

Surely there are serious technological and cultural challenges in embedded in each of these items.  However, I assert that for the most part these issues aren't unique to EDA, and that all three are common to the broader SaaS world.  Consequently, I argue that EDA will be able to successfully piggyback onto the various solutions for these issues that the greater SaaS world is developing and/or deploying now.

To summarize this whole SaaS + EDA discussion, re-consider the following assertions I made up front in Part_1:

  • None of the SaaS objects the panel identified will block significant adoption of SaaS by the EDA industry, within the panelists' general consensus time frame of ~5 years.
  • EDA applications that easily leverage multiple CPUs will surely be in the vanguard of this movement, with all other EDA tools eventually migrating to the cloud as well.
  • In many ways, it's not terribly important to me what platform my products run on, as long as someone wants to run them!  ;-)  Seriously, whether it's a local farm of Linux boxes, Suns, AIX machines, or some remote, virtualized cloud of processing power, it's the applications themselves (and methodologies that help users extract the most value from said applications) that's most important to the end user.

Reference links:
The last 4 frames of this set are photos from the DVCon 2009 SaaS panel: http://www.flickr.com/photos/24605532@N08/sets/72157614375923457/

What Cadence offers in the SaaS space today (in short, just about everything):
http://www.cadence.com/products/hds/Pages/Default.aspx

The Xuropa Online Lab
http://xuropa.com/index_online_lab.php 

Panel moderator Harry "The ASIC Guy" Gries' site/blog:
http://theasicguy.com

 

Joe Hupcey III

 

Comments(2)

By Jeremy Ralph on March 30, 2009
At PDTi we have a SaaS register-map specificaiton and generation tool that has been used by many companies for evaluation and production.  Multiple ASICs have been taped out using this. Check it out at http://SpectaReg.com.  There is also an on-premise version.

By Jeremy Ralph on March 30, 2009
There is a EDA SaaS Enthusiasts LinkedIn group with more than 20 members that readers may be interested in joining:
www.linkedin.com/groups

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.