[content] => 
    [params] => Array
            [0] => /forum/index.php?threads/eppur-si-muove-and-yet-it-moves-%E2%80%A6-to-the-cloud-and-beyond.1454/

    [addOns] => Array
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2020871
            [XFI] => 1050170

    [wordpress] => /var/www/html

Eppur Si Muove (And Yet It Moves)… to the Cloud and beyond

View attachment 3331
And yet it moves (Italian: Eppur si muove; [epˈpur si ˈmwɔːve]) is a phrase said to have been uttered before the Inquisition by the Italian mathematician, physicist and philosopher Galileo Galilei in 1633 after being forced to recant his belief that the earth moves around the sun.”(1)

As I was driving from Monterey last week after attending the Electronic Design Process Symposium (EDPS), this sentence kept popping in my head when I was mentally re-arranging the various arguments in support of or against EDA in the cloud. I am identifying with Galileo lately while feeling his pain. I have been evangelizing the merits of the EDA in the cloud for a while now, and yet the clamor about the death of an approach towards EDA transacting is rising when it has not even had a chance to be properly deployed. So I decided to list all the various objections and dismissals of CloudEDA and attempt to rationalize, debunk and yes speculate since this seems to be one of the currencies in vogue these days. To keep things on the lighter side of this serious topic, I will sprinkle as many clichés or sayings that I can think of (for or against, with or without mangling mind you) and we will together keep track of them until the clouds come home [1].

- It is the (lack of) security, stupid [2]. One of the most recurring theme, loaded with FUD. There is security, trust us. Fortresses are better than huts, no matter how valiant the warrior. Encryption, protected access, the foundry already has your jewels, if you are IP paranoid, get your own fortress, but pay as you go for what you need. Do not let the exception drown the rule. Next question.

- Been there done that [3] Some have said that they tried this years ago and even recently and customers would not belly up to the bar and lawyers would not let go of IP and finance would not budge and the dog ate my homework [extra credit earned here for humor]. The simple answer is ‘it depends’ on the deal, the terms, the past is not the future or even the self-fulfilled reality. Try, try again, because there is real money behind them servers you never have to buy, maintain or upgrade. Are you listening EDA? The pricing is getting lower when you look at costs and the revenue is getting higher when you look at ‘useful use for what you need’ not ‘inefficient use for what you have to eat’ by customers who are happier because they are getting their work done faster and thus will come back for more. Big companies have budgets and few have unlimited resources. It is elementary ‘efficient markets’ economics my dear.

- ‘Show me the money’ and its cousin ‘Follow the (lack of) money’ or ‘Cost too much money’ or ‘What happened to my money’ [4]. The last one refers to impact to short term financials if TBLs are redone. True enough but the pot is at the end of the rainbow in that your patience will be rewarded later, and you can always phase this thing in by staging pilot engagements, playing with the transaction options and experimenting.

- When it pours, it will therefore rain [5] In other words, let Mikey try it first. If it works, I will join in. I only have momentum to lose. Right.

- Where is the beef? [6] See [4]. Where is the research? It does not exist because the market is in its early stages, nor is research needed if you think about it. No $5B capital is required before you start. Try it. With passion, not skepticism. It could be good.

- If you build it they will come [7] Now you are talking.But you never said that unfortunately.

-Yes, No, Maybe, I don’t know, Can you repeat the question? [8] I am confused. Can I hedge? How is that different? If you have to ask, never mind then.

- This is rocket science, not an app [9]
View attachment 3330
(Henry Blodget CEO Business Insider, March 21, 2012)

Yep. Let us make it an App. Moving to the cloud and doing everything in the cloud is just like doing work today and no code rewrite is needed. You are hosting there, not here. So it is neither here, nor there and is getting us nowhere. I am oversimplifying here in terms of code rewrite. We really should disaggregate the tools into features as apps. I used to buy a commercial application for $300. I buy it now from the same vendor at $10 but I buy 40 more apps. So I am spending $100 more, I do more with apps I actually need, not less with ones I pay for but never use in ‘all-you-eat’ scenarios. Some apps are rocket science by the way but I digress.

- There are not enough users, the long tail is short and we are chasing our tail [10]. It is not worth it they say. There are indeed a few thousand designers. I think the constraint is a result of million dollar tools forcing limited grand priests to manipulate precious resources. That is our opportunity to grow the user base. More power to more people trying to design for less power. Streamline the flows, layer on the methodologies, and interoperate. Lots of development opportunities exist for better design experience.

- Self-inflicted irrelevance [11] Often mentioned by cloud advocates.VCs do not like semis and EDA anymore. Let us give them a reason to get excited again by being more creative and aggressive in business models.

- Do not rock the boat while I create yet another unneeded tool duplication no-one wants [12] This is the reason why the excitement is gone. I can see you nodding or shaking your head. Discuss.

- Why ask why [13] That is how things have been and likely to stay. In reality the singularity is not near but is occurring already and it appears more likely end-games could occur with foundries becoming more likely to incorporate the tools as part of their overall offerings, facilitating further process and tool interdependencies. This has been talked about for a while, but the murmurs are becoming drumbeats. All it takes now is a motivated 3rd party to encourage this path.

- It is a jungle so I will bear hug only gorilla customers, the rest are toast [14] There are only large customers left and they do not want common cloud. Yet that 3rd party in the above paragraph is a gorilla customer realizing design enablement also could include one stop shop. That same gorilla customer may actually insist on maintaining multiple foundry options, but with EDA baked in in each option. Creating an alternate enablement through the cloud could address everyone’s wants and needs since the foundries model will be one of the incarnations of this use case and not just the one incarnation.

There are always 10 reasons not to do anything but only one is needed when it is the most important reason. That reason is: we need a change in attitude, altitude and fortitude (that is 3 for you who are counting, but who is counting?) Feed the cloud, starve the fear.

Eppur Si Muove. Ipso facto. Non sequitur. Alea Jacta Est.

- Note: Mixing metaphors here while putting down my foot where my mouth is, I am thinking of helping organize a seminar-panel combo session during the upcoming DAC where we can discuss this topic. I am thinking a 3 hour long one with EDA, foundry, cloud provider, FPGA, IDM, VC, startup, server and analyst, academic and IEEE luminaries. We would invite the public and public comment to help shape the agenda with a soft or downloadable copy of contributed content provided at the end of the seminar along with some giveaways. With visions of John Belushi running out of the Animal House frat house trying to energize his peers, yet finding himself by himself, I am asking here for feedback on whether this would be a good idea. If you like this and happen to be a willing sponsor, do let me know. Otherwise, this may end up a pub discussion where paper napkins become the presentation sketches. Of course if something similar is already occurring, can you let me and the readers know? Thank you in advance.
Last edited:


Active member
I think what is missing in "EDA in the Cloud" is the Angels.
You should be able to have an idea for an SoC and then find a company that will give you a very good guess as to the development time for HW/SW, development cost for HW/SW and final per piece cost of your SoC (including yield, etc).
Even if you can have your simulation Server needs taken care of by Amazon EC2 you still need a mountain of people in your payroll and/or as partners to get you the numbers above.
The Angels in the Cloud will be able to work with your CTO to make his/her vision a reality.
Posted by Raul I Lopez


New member
I actually think the lack of movement toward cloud by EDA is simple human nature. Cloud is a disruptive innovation from a business model perspective. From a technical perspective, the only real difference from what everyone has today is in implementation. The real devil here is "change".

(1) The cloud vendors have a business model (and technical implementation) that works for them, maximizes their yield, and has been communicated to the teams in a certain way. In order to work well for EDA/Semiconductor customers, the customers would like to see a change in the solution offering (more tailored to specific customer needs).

(2) The C-levels at the Semiconductor companies are interested in Cloud because it promises to give them much of what they have been asking for from their internal IT organizations for many years, and have yet to really see. Those C-levels then request their internal IT organizations to qualify this new thing (Cloud), and the internal IT organization see Cloud as lots of change to their existing process and maybe way of life.

(3) The EDA vendors are also open to the idea, but they always ask the question of how does this change what they do today (sales, revenue, margins, etc.), implying that they will gladly do it as long as nothing changes…

(4) OEM Hardware vendors are also willing to help make Cloud happen, as long as customers commit to buying upfront in significant enough quantities to pay for everything in the first year. This is no different than a creative finance model for the same sales cycle they do today.

(5) Legal teams at Semiconductor companies have no compliance organization or certification body to reference, so change is risk.

So everyone is okay going to cloud as long as THEY don’t have to change anything that they do… Human nature :) Change is risk, and why should I risk anything unless I am going to get a benefit for me… each of the five perspectives is solving the equation to optimize on a single variable, and that variable is different for each perspective.
There is certainly an opportunity for 3rd party developers (like your Angels) and EDA embedded teams to start providing value-add services and offerings. One that is definitely needed is the streamlining of methodologies and flow interoperability. Large IDMs are doing this but the majority of the mainstream users lack that guidance.

This change is certainly disruptive but I view this as needed to keep up with the changing realities of technology commerce. We are slowly losing the creative edge (to social media and software infrastructure) and we keep sustaining instead of re-inventing the transaction models.
On your points (numbered to match your list):

(1) The cloud vendors are learning the EDA business and have revised their pricing and models to stir up demand. What really puzzles me is that Amazon (a bookseller and merchandiser) is more creative that we (semi/EDA) should have been seeing the potential of this. Customers have started weighing in on their solution needs, but have been slowed down by the IP/legal/security impediments (your #(5)).

(2) Agree. the C-levels will always favor more efficiencies and cost reductions. The smart IT organizations of the semi are remixing the IT talent to optimize cloud service, but the bias is still for private cloud, a warmed-up version of the same old thing, without the inherent EDA benefits of scale beyond individual organizations in provisioning and cost savings.

(3) The EDA companies support this model if it sustains their revenue and does not disrupt it short term (understandable). They will gladly do this if large customers insist on it. I contend that there is money left on the table or wasted (cost wise) by ALL parties by not shifting to cloud. Pay per use will encourage efficient use of needed tools by customers, accelerating schedules, making them glad to pay more for more results. EDAs expand user base and usage and reduce costs. Large companies could be possibly using their scale and purse for competitive advantage, but last I heard they are still buying start-ups who are actually EDA constrained today. Let us liberate them both then with a transaction friendly to all. So I would say they will gladly do it if they minimize short term risk. Even EDA sales can warm up to sustained benefits.

(4) OEM hardware vendors are actually pushing this because it simplifies their sales cycle. Five sales to mega-cloud aggregators are more efficient than hundreds retail sales to IT departments. Either way storage and servers are going to be needed. We need them to actually subsidize the EDA dipping their feet in cloud so EDA has time to smoothly transition to the new model.

(5) It will take executive directives to get legal to accelerate the compliance otherwise the logjam will never be broken. This reminds me of the IBM example cited in a panel at a conference where internal multi-site design was cloud centralized and implemented only after it became a 'condition of employment'.

So my message continues to be: Embrace the change, it could be good. :)
Thanks to both of you for the judicious insight.

I'm shocked that you did not have an "ace up your sleeve" in this write up.....or was it a 'sleeve'?

Scott hit many of the right topics and that basically change is very difficult: whether adopting technology, changing jobs or even changing governments. Over this past year, we have seen pent up frustrations changing governments in Africa and elsewhere. Status quo is much easier and requires less energy (you could draw more physics into this about static objects and energy to cause motion...or conservation of energy or....). On the financial side, publically traded companies ned to continually 'hit their numbers' to increase or maintain their stock price. Anything that can cause increase risks in this area will dampen change initiatives (new business models, unknown revenue forecasts, etc). The fact that Amazon is looking at different business models does not surprise me. They started out as a new business model from an MBA thesis (if I recall correctly) using latest technology. EDA has been around ~30-40 years (various levels of SW tools) and has built years of experience that continue to be successful. You can question if it could be more successful, but looking at the EDAC numbers EDA continues to grow. Continued growth is not a compelling event to cause change. Rapid change happens when you have big pain, very slow/snail pace change is when little or no pain exists. Look at the airlines over the past decade. Some had huge pain about a decade ago and needed to declare bankrupcy and re-formulate their business. AA is going through this now. They have huge pain.

Is the cloud viable? absolutely. Lots of people are using the cloud today and may not even know it. Any one with ebooks is storing or can store purchased books on remote/non-owned servers and download anytime they want a specific book back on their reader. My doctor is now having records on a secure sight so you can login and see test results, etc. Private clouds or server farms have been around for a long time and used for extensive regression testing. So it is probably a matter of time for anyone (the masses) to get access to cloud and eda and services. I would not be surprised that a service organization already exists that is based on cloud and they are the gatekeeper to this cloud. They provide services based on cloud/SW that they own.

It's a matter of time before 'mainstreet' is comfortable with cloud/eda. The innovators/early adoptors are using it. Geoff Moore's Chasm model might be perfect analogy for cloud/eda.

Where is that ace again? :p


Re: Aces, sometimes they are not the whole story... That story was so good, NPR thought it worthy of broadcast.. For all of you out there, Bill is referring to an 80's misquote of the century by yours truly.. Look for an upcoming write-up which will caution about language pitfalls where the Ace story will be told.

Re: Cloud, I am convinced of the when, not just the if. The when is way overdue. The why is clear, the who is now starting to take shape.
Of course there are many reasons to explain this. I think explaining is becoming irrelevant, when 'Just Do It' will suffice. You can quote me on that, not the Ace :D. Thanks for chiming in.


Re: Aces, sometimes they are not the whole story... That story was so good, NPR thought it worthy of broadcast.. For all of you out there, Bill is referring to an 80's misquote of the century by yours truly.. Look for an upcoming write-up which will caution about language pitfalls where the Ace story will be told.

Re: Cloud, I am convinced of the when, not just the if. The when is way overdue. The why is clear, the who is now starting to take shape.
Of course there are many reasons to explain this. I think explaining is becoming irrelevant, when 'Just Do It' will suffice. You can quote me on that, not the Ace :D. Thanks for chiming in.

Actually it was mixing metaphors with Sr mgmt between 2 companies. Needless to say, it was like EF Hutton was making a commercial back in 80/90's and everyone stopped talking and looked at CK. I am sure we left an impression with this customer....


New member
I think there are many reasons why change is hard, but here is one that I think is effecting this scenario. Speaking primarily from the perspective of the Semiconductor infrastructure side, evolution is partly to blame for change being so hard. As capacity demands and complexities continue to grow within the infrastructure, the workload to support that increases geometrically. As a result, the type of work that gets executed changes to adapt. Traditionally, environments would be made of 3 different types of activities – operations (day to day maintenance), tactical (evolved solution design, internal analysis), and strategic (new solution innovation, R&D, external analysis). As workload increases, urgent work is usually prioritized first, and the urgent work is always the operational pieces (engineers in crisis). As more operational work needs to be executed, the long term strategic work is what suffers first, because that can be done later. Eventually, no strategic work is being executed, and only tactical and operation activities survive. More operational work then cuts into the tactical work, and soon, only operational work is being executed.

Most companies have stopped innovating because everyone is paid to maintain the status quo (that really is all they are budgeted for). This is the single biggest reason companies fail to do anything new or exciting. Everyone is maxed out keeping the fires low (they seem to never go out completely); innovation is requested as a “spare time” activity. Despite the real risk involved, this actually makes sense. Companies are focused on doing one thing very well. In this case, design semiconductors. All of the roles in the company are defined and structured to create the best environment for designing chips as efficiently as possible. Success is doing the same thing the company has always done, just a little bit better, a little more cost effective. This means that making things static so that their process can be improved upon (made more efficient, more cost effective) is encouraged, which mean change is discouraged by time constraints and the stifling number of external adjustments needed to existing process, procedure, and documentation. Any innovation needs to be executed first time right, and innovation is many times a process of learning from failures. Every day becomes the same battle to control the chaos of daily activities due to increasing demand for capacity and performance, but constrained by budgets, static environments burdened by mountains of bureaucratic red tape and a lack of innovative infusion.
Scott: This is very much the situation these days and is understandable from the overextended perspective of infrastructure organizations. Keep treading with diminishing returns. The IT fabric should be empowered in the transformation and tasked as full partners with new priorities. Sometimes quantum leaps are needed when gradual changes are not sufficient.. I am not being simplistic, I see the challenge. We need to work very hard still, on different stuff though..