Never miss a story from Functional Verification. Subscribe for in-depth analysis and articles.
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:
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 VerificationAs 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 parallelBeyond 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 evaluationsYes, 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?
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:
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 Labhttp://xuropa.com/index_online_lab.php
Panel moderator Harry "The ASIC Guy" Gries' site/blog:http://theasicguy.com
Joe Hupcey III