EDA Clearing Clouds or Cloudy Computing?

[Camille]

Other than providing a plethora of catchy titles and vivid imagery, the term cloud computing is in need of an identity change if not permanent retirement. For one it does not mean anything. Clouds do not compute. This meme has run its course but the underlying concept it brings has yet to unfold to its full potential for reasons listed below. By this I mean the reasons why it has potential and why it has not yet unfolded fully. The potential of this emerging discipline/capability is enormous and should mean a lot. A lot of cycles, a lot less overhead, a lot more utility, a lot of results, a lot sooner. For the purposes of this post let us rename cloud computing pervasive on demand utility computing and let us examine the interesting angle of delivering EDA tools via this mechanism.



I have written about this topic before. What has made this computing model attractive is the continuing decrease in hardware and related servicing cost of the Information Technology infrastructure if applied at a large scale, the improvement of secure access and hosting and the strides made in addressing requirements of software-as-a-service from a workflow and invoicing standpoint. A seminal Berkeley paper published in 2009 defined the computing paradigms and associated economics and benefits of this utility computing model.

The ‘EDA in the cloud’ compelling proposition includes the following considerations:

• Increasing Design Complexity requires large computing resources that work better if distributed over many servers, specially at key steps (regression tests, logical and physical verification and so on).

• Peak usage can be easily handled with paying only for resources used for the needed tools and only for the duration used without worrying about hardware infrastructure deployment, upgrade and maintenance.

• Concerns about security have largely been addressed, through encryption, secure access.

• Data integrity, version control, backup, disaster recovery and multiple-site collaboration mandate location independent computing and information content storage.

• Flexibility in using best of breed point tools versus one stop shopping with captive flows.

• The computing requirements are increasing so quickly that the logistics abilities for individual organizations to upgrade and maintain are being challenged. The cycle of upkeep includes managing increased storage, CPU, memory, license needs with support personnel in CAD, IT being required by providers and users alike where applying scale may not make sense economically if surge demands are existent but not frequent.

• Standardized reference flows are making it possible to have scripted and homogenized design techniques and solutions applied in a design factory mode where scripted jobs are sent to be run and examined later without incurring transacting costs for viewing and analyzing.

• Foundries are increasingly becoming a natural host for design IP, content and information repository for key process and manufacturing information that goes along with design content information such as design kits, third party IP and waivers or process rules.

• Start-ups may be able to afford the use of expensive tools and so will medium and large companies who could restructure uses for project activity-based accounting that will be able to measure ROI and value propositions on a more granular basis instead of spreading EDA costs ‘peanut-butter style’ with no ability to know what was used, worked or even abused.

The challenges for on-demand computing are:

• Disruption to a key traditional EDA transacting model which relies mainly on multiple-year time based licensing with incentives for all you can eat, one tool provider maximizing the share of increasingly challenged and limited budgets unable to keep up with the rising cost of development and thus constraining either productivity or choice when alternative choices may be better for some focused tasks. Clayton Christensen’s Innovator’s Dilemma states that disruptive technologies can make successful companies fail if they continue doing what made them successful in the first place.This is a call for action of sorts to all stakeholders.

• Concern that EDA development will shrink if perceived returns are no longer projected to grow. One might counter that growth is challenged already in EDA and that moving to on-demand computing could in fact energize the industry with new tools/solutions approaches and with possible new entrants or extended use by existing customers who find that more can be done if capital and operational expenses can be dispensed on an as needed basis as opposed to sunk costs whether a tool or a server is used some time, all the time or in some cases not at all but is there because it was bundled. Not to mention the planning flexibility afforded by on demand resourcing.

• Intellectual Property Security as an issue keeps coming up even though technology has largely addressed this with tagging, encryption, provision of binaries, and access control and monitoring.

• Pricing models have to come down and they seem to be scaling down driven by key infrastructure providers and operators. As it currently stands many departments can build a case for continuing to build their own infrastructure even though they would not mind trying public cloud implements if the price is right.

• Job security is another factor fueling uncertainty and doubt. Concern about CAD departments and IT organizations becoming impacted is sometimes voiced, more often feared. The fact that restructuring is inevitable does not mean though that jobs will disappear. The thriving software infrastructure industry is a testament that job growth can exist if novel solutions are being applied to the EDA industry. One might even say that the EDA industry is missing out on all the innovation taking place in the social media and web 3.0 activity currently occurring.

• Standardization of transaction models and homogenized look and feel for the end user so the experience is wholesome, systemic and predictable. The EDA industry here needs to step up and collaborate instead of going its own individualized way of deploying cloud constructs which could actually be less revolutionary, and more biased towards own strengths instead of looking at enabling the whole ecosystem in a cohesive manner.

• One real challenge is the various unique use models that end-users or departments have. One EDA executive correctly pointed out that it is hard to get two departments to agree on what to use and how to do things and where to do it let alone having the whole industry or ecosystem concur. The way to address this is to have a top down driven imperative at the corporate level and a concerted industry action to coordinate best practices, models and transactions while preserving their own proprietary pricing and strategies of what to build, how to create the code and who their audiences are intended to be.

I was very encouraged by the cloud panel session at the latest DAC in San Diego. There was the beginning of realization of doing something by EDA vendors, start-ups, users and foundries. The language has started shifting from denial and providing reasons not to do anything to articulating a wish to get there and voicing a commitment to address the challenges ahead. Jacques Lacan, a French psychoanalyst, stated it neatly by stating that ‘language points to a lack’ which loosely translated means ‘if you are talking about it, it means you are not getting it’. To be sure, I do not want to oversimplify the challenges which are real but I do think we have to start tackling this with more bravado, eagerness and open mindedness and with less sub-optimizing half measures.

What do you think? Is it a hype, myth or a new reality? Inquiry minds want to know.

[George Storm]

A couple of half-baked thoughts:

Hardware and infrastructure costs appear relatively small compared with software and support. For moderate-sized companies the major benefit would be a "true turnkey" solution.

Perhaps the "ideal" cloud provider would be closely aligned with the foundry? This would relieve fabless houses of the hassle of kit installation and maintenance. The foundry is probably also in a good position to negotiate a good deal with the EDA providers.
There could also be advantage for any foundry that invests in extended models, interoperability, specialised tools, etc. - as IP leakage becomes more controllable.

[Camille]

Great comments, George. On your first point, you are correct that hardware and infrastructure costs are small compared to software and maintenance but the challenge is the latency between upgrading and using the infrastructure unless you over-provision which could be costly. On the second point, foundries are absolutely a natural for providing the launchpad with pre-installed kits and configured environments with secure IP portals and pre-negotiated foundry rates from EDA suppliers. One incarnation could be foundries bundling this as a service to customers. This is how our semiconductor industry got its start: foundries providing design services, tools and manufacturing in one stop shop. Back to the future? By the way EDA can still prosper in this mode of fewer but larger buyers of tools.

A couple of half-baked thoughts:

Hardware and infrastructure costs appear relatively small compared with software and support. For moderate-sized companies the major benefit would be a "true turnkey" solution.

Perhaps the "ideal" cloud provider would be closely aligned with the foundry? This would relieve fabless houses of the hassle of kit installation and maintenance. The foundry is probably also in a good position to negotiate a good deal with the EDA providers.
There could also be advantage for any foundry that invests in extended models, interoperability, specialised tools, etc. - as IP leakage becomes more controllable.

[George Storm]

"foundries providing design services, tools and manufacturing in one stop shop." Back to the future? By the way EDA can still prosper in this mode of fewer but larger buyers of tools.

Actually, this model is where some of us started - albeit the "foundry" was an IDM's in-house fab, the "cloud" was a shared "supercomputer", and the data was exchanged in (tedious) text format over a modem. This was of course updated using intranets, and thence -at least partially - transferred to secure access over the web; however, this model remains pretty-much restricted to IDMs. More recently, since the onset of general broadband access, it should have become a practical and convenient possibility for foundry suppliers and so for fabless users.
So why has it not happened (yet)?
Given that this would also potentially remove some of the day-to-day support that foundries in practice provide multiple small users, my guess would be contract-conservatism on the part of EDA companies. Am I missing the critical issue, perhaps?

[Camille]

@George: There were initially some valid reasons not to do it in a public cloud setting (screen response time was sluggish for interactive work, security was not guaranteed, design collaboration was not practical, server scaling expensive and the application designs just did not require the compute capability). What does remain probably is some concern about short term revenue impact from large EDA vendors (a possibility but the long term outlook may be worth the hassle). I think contract-conservatism may be less of an issue with smaller EDA. My personal gut feel is that there is actually unrealized revenue to be made by all of EDA if transacting over cloud goes mainstream. There will be more use by more users on most tools. What may not be used will be sub-par tools, but that is a threat and an opportunity for all tools to improve. This reminds me of when DVD/VHS sales were thought to reduce movie theater revenue by Hollywood. What happened of course caused revenue to rise through this new channel. Even if ticket sales were impacted, Hollywood made out well in the final analysis.

[George Storm]

I wouldn't argue most of this, although I would have thought that the higher the cost of computing the more cost benefit would accrue to sharing the resource.
Of course, hardware is no longer the dominant feature for designers of modest systems, but I suspect that the relative cost of hardware required for finishing (full chip analysis, layout and post-layout simulation) is actually continuing to increase as design size increases, so even the hardware motivation will remain in place for high-end users.

[a.a]

EDA clouds make sense, but it would take time for customers to agree to relinquish control over the software. For instance, as we speak our company about to roll out cloud based lithography simulator.It can process more data faster than any other commercial optical simulator. I can prove that. But...

I know that promoting the system will be very difficult. Sending design data over the internet seems to be giving a fit to the very people who bank and buy online every day. The tidal wave will come, but it is not there yet.

[Camille]

@a.a : True enough. The same reluctance happened when internal IT departments started requiring design data to be moved from the engineer's desktop to a central file system located inside the corporation. At some point, it made sense to just do it and engineers adapted. The challenge is to highlight the positives and not make it feel like a take-away.

[Daniel Nenni]

SemiWiki is in a private cloud that is optimized for MySQL. They handle software upgrades, bugs, tuning, and other DBA stuff for people like me who would rather be doing other things.

Cloud also offers the EDA industry the opportunity to move towards a success based business model rather than the cancer like "all-you-can-eat" licensing we do today.



Unfortunately I do not see EDA cloud success on the horizon. I will ping the Synopsys cloud guy David Hsu and see if he will give us an update. Maybe James Colgan, CEO of Xuropa can chime in as well.

Cheers,

D.A.N.

[Paul McLellan]

One of the things that I see as a big challenge is the volume of data in EDA. If we are just talking about a customer setting up their design flow using something like Amazon AWS then fine. But if we are looking at something more like the Salesforce.com model whereby different EDA vendors have cloud offerings, then a mixed flow (and all flows are mixed) requires the data to be moved between different sites. Salesforce.com would work a lot less smoothly if every day or two you had to move the entire CRM database to Oracle and back in order to get access to some feature Salesforce.com lacked. And that database is small compared to the polygon level of a modern chip.

Paul