EDA In The Cloud (Part 2)

Experts at the Table, part 2: How should tools be licensed for the Cloud, and what is the first application that is likely to see mass adoption.


Semiconductor Engineering sat down to discuss the migration of EDA tools into the Cloud with Arvind Vel, director of product management at ANSYS; Michal Siwinski, vice president of product management at Cadence; Richard Paw, product marketing manager at DellEMC, Gordon Allan, product manager at Mentor, a Siemens Business; Doug Letcher, president and CEO of Metrics, Tom Anderson, technical marketing consultant for OneSpin Solutions; and Kirvy Teo, vice president of business development at Plunify. What follows are excerpts of that conversation. To view part one, click here.

SE: How will the Cloud impact licensing?

Allan: We don’t need to be shackled by license count anymore. In the Cloud, there are other ways to do accounting using other mechanisms and the container approach. We have sold unlimited licenses to enterprise customers and unlimited licenses to startups while they are on a ramp. We are selling a capability rather than a count of licenses. There is a middle ground where we need to address flexible business models and enable the engineer to write a check to cause a burst to happen. If he is using a formal tool and wants an answer to the problem right now – if he can burst that to 1,024 processors, then he will get the answer. But how does he write the check to spend that?

Siwinski: More than decade ago we started shifting to a time-based licensing model. Now we debate how granular it should be. Should it be per minute, per second, per day? That becomes a question of math. Assuming you have the infrastructure and that you are not thinking about perpetual licenses, instead think about it as a service that is provided and that there is some way to monetize it based on usage.

Letcher: It has to be more granular than it is right now. Look at the Cloud vendors themselves. You could rent by the day, then they went to the hour and now to the minute. Customers want the flexibility to use it in whatever way they need.

Vel: What customers are looking at is your core/hour efficiency. How can you solve a problem with a number of cores, how many hours you are using it? As long as you can add the number of cores and the number of hours, you have a true metrics of the number of core-hours needed to solve the problem. The more efficiently you solve it, the more customers will pay. In terms of licensing models, it is in the works but has to evolve within the community. Today, we are at a time-based licensing model where you have a yearly lease, or six-month lease, or it’s monthly, but it has to come down.

Siwinski: We are further along than that. Some of us at the table have more flexible models than that already. Customers will want to use a tool for a duration. Some of the models are not well publicized yet and not everyone uses the same terminology, but just like all transitions, we will all get there. If we have this roundtable a year from now, I guarantee that we will be at different point. That is why we are all here at this table.

Teo: There is a difference between the bigger companies and the smaller companies in terms of pricing. Some of the things that have been tried are based on quality of results rather than the number of cores needed to run a job. At the end of the day they just want a good result. Supposedly being faster will get you a better result, but that is not always true. So we have tried success-based service.

Anderson: EDA has been trying for 30 years to find how to charge for value, charge for service.

Siwinski: Everyone has tried a key performance indicators (KPI)-based approach and they have had mixed results.

Anderson: Or some kind of royalty approach. None of it has caught on. The Cloud is challenging us, but it may be forcing us to solve a problem that we have to solve anyway.

SE: A lot of the discussion has been around the topic of simulation. Is that the sweet spot for penetration?

Letcher: It definitely seems to be the killer app for the Cloud because it is so elastic.

Siwinski: A few customers have commented that simulation, both digital and analog and everything in between, accounts for more than 70% of overall compute. Smaller companies may be different, but if you look at mid-sized and upper-sized companies that have a broad range of applications, simulation, emulation — they are compute intensive.

Paw: It is the nature of the job. Twenty years ago they were saying that verification is 70% of the design cycle. It hasn’t changed. What you are seeing in the data center is that 70% of their usage is simulation. So you have the most compute being used there, you have the largest number of tools being used there, as well in terms of instances of tools. They are parallelizable, and the jobs are atomic to themselves. So they lend themselves to a Cloud model very well, more than any other job profile. Characterization is similar, but you don’t have the same scale there. That is the sweet spot because of the nature of the workload.

Siwinski: Plus, with design complexity you are talking about verification being 2n or at least n2, so fundamentally verification will always be more complex. Who has a customer who will tell you that you are done, or that they have enough licenses for verification. That does not happen.

Paw: With EDA and chip design, you never are really done with verification. You verify to what you can afford. You have a set amount of money and you buy licenses and verify till you run out of money. You never get to the point of being happy, only good enough.

Siwinski: Cloud changes the conversation from a CapEx conversation to an OpEx conversation, or a variety of both. If you have a need, an OpEx conversation is often easier than CapEx. Not always, but it has more flexibility.

Vel: What we are seeing is that the amount of verification you do is essentially increasing. As people move from one technology node to another, they have to do 2X the amount of verification just because they move to the new technology node. It is not just functional verification anymore. It is physical verification, new types of electronic verification, thermal, power, safety. All these types of verification have exploded exponentially. To be able to do that amount of verification in a short amount of time, with a model that works – that is where you have to be looking towards the Cloud. It is the only thing that can help to solve these problems.

SE: Is it enough to just have the point tools in the Cloud or do you have to migrate an entire flow? If we have all of the simulations running, do you want to be pulling results back down for bug triage, or do you need that to happen in the Cloud, as well?

Allan: The Cloud gives us opportunity for new flows. A triage flow is an example. Consider a simulation task that is done while the engineer is asleep. He wakes up in the morning and wants to be productive. What can we accomplish in that time? We have a fixed number of compute resources and licenses. Should we do what we can in that time, or can we leverage Cloud elasticity to get the job done so the engineer is guaranteed to be productive when he arrives? The simulations are done, the triage is done, the debug reruns are done, and he has something ready to debug on his screen. That is a model to enable productivity.

Siwinski: You can take that approach with simulation or emulation or formal or specific point tools. If you approach it as a verification task, then it gives you the flexibility to look at suites and continuums. Fundamentally, the underlying engine is secondary to the task you perform EDA will do a better job trying to pick the right engine for the challenge, but you do it in the Cloud and then fundamentally what happens is you are generating oodles of data. And right there is an opportunity for Big Data analytics that should be in the Cloud. Why would you try and bring that back to your own private compute? Then why not apply AI, machine learning — you name it? Now it starts to become much more interesting and the Cloud becomes the underlying foundation for that. Without that you won’t get the scale.

Vel: It is not really about applying it to one silo of data. When you look at Big Data, every EDA tool can generate TeraBytes of data. Then you have all of these silos from verification to power analysis to noise analysis, to thermal analysis. What does it take to be able to combine all of these analyses and pull out actionable analytics? It is not just about analytics, but how you act on them across the various types of physics. It is a multi-physics type of problem that needs to be solved. Today we do not solve one problem with thermal. We are not saying, ‘The chip is getting hot, so fix it.’ We are saying that the chip will get hot, the product will degrade, that will affect the lifetime in the automobile, and that will cause it to fail ISO 26262. Everything has a trickle-down effect and we need to put them in the context of each other, in the Cloud.

Anderson: You need something that you can act on. The more it becomes a closed loop running in the Cloud, the better for everyone. You should, in some cases, be able to do something about it even before the designer sees it. The notion that you want to perform deep analysis and verification is an integral part of that. If you can take the data and act on it in a way that automates and feeds back into the Cloud, then great.

Vel: The last thing here is that right now we are looking at analytics as being purely prescriptive analytics. We need to move from this to predictive analytics. That is where machine learning comes in. Even before you have a problem, you want to be able to look at analytics that suggest you are heading toward the problem and tell you in advance. Tell the designer that they need to start doing something different.

Paw: Any future EDA flow has to be flexible enough to handle a hybrid Cloud environment where some of the jobs are run in-house and some on the Cloud. Most large companies outside of EDA have hybrid Cloud strategies. We talked about how the Cloud is safer, but we know they have breaches and usually it is the customers fault. Large companies will look at it and looks at the risks and the most sensitive stuff may never leave the datacenter. That may just be a reality. If it is inside your walls, it feels safer. Any flow must encompass this.

Letcher: That might be true for the biggest companies, but anyone smaller than that should not be running their own datacenter.

Paw: Right, it is the biggest guys who will use the hybrid model.

Siwinski: Even for the smaller ones, they will not run a datacenter, but they will still have some localized compute. If you are dealing with low-latency applications, you want an instant response. Many tasks are interactive. It is still a form of hybrid. It may be only 10/90 or even 1/99, but the architecture still has to take this into account.

Paw: Flows will have to take into account that some of the data is local and some is not. It has to know how to handle that.

Letcher: How you integrate these flows is important. It is more than just putting some licenses in a Cloud datacenter and letting them run. You need proper web-based tools that allow people from a local site to interact with the remote data without having to bring it back.

Paw: Except that you have customers who like to build their own stuff. EDA companies are DIY. It doesn’t matter if you give them something or not, they will do it. The industry’s job is to make that easy and efficient.

Allan: It has always been that way, but we do adopt the best practices of the software industry and use continuous integration and configuration management systems. Vendors could include this in their Cloud offering, even more so. Once you host your source code in the Cloud and do the development in the Cloud and enable multiple geographies to participate, then the opportunities really kick in for deep learning. How can you gather data from all of the activity and use it to inform yourself in the future? I do not see problems – only opportunities. The balance has tipped. Seven of our top 20 customers have this on their radar or are already using our tools in the Cloud.

Siwinski: I would say that the percentages are even higher. Some of the companies that are still struggling are those that have no internal policies. Sometimes the conversation is really a CIO conversation about their Cloud policy. Do they have one in place and then partnering on developing that policy. A piece of paper dictating those rules needs to exist in a lot of these companies. For a startup this takes about one minute, but for larger companies it can take six months. There have been some that have taken over two years to start a policy. But once you have a policy, this is just elastic compute.

Paw: For the large guys there is enterprise IT and engineering IT. I expect most enterprise IT guys have a policy in place. Engineering IT may not at this point.
Siwinski: Maybe. Most companies have policies for the Cloud, but the policies for the semiconductor content and design – the jewels of the corporation that might be exposed – are a lot less taboo than before. But not everyone is there yet.

Letcher: There is an additional issue beyond your own IP. What about external third-party IP? You have to get permissions to make sure what you can move.

Siwinski: That does impact some of the notions about what is plausible on the back-end. Not all of the foundries want to be sharing everything, whereas you can argue that in the front end it is a little bit easier. Specifically, if the Cloud is a permutation of a third-party server, then the same access rights apply and so IP should not be a problem.

Anderson: Putting a mask in the Cloud certainly feels a lot more risky than putting RTL in the Cloud.

Letcher: It is psychology.

Anderson: The design is often not the crown jewels. Would you rather have your entire sales force database hacked or your RTL hacked?

Letcher: We have certainly had customers say that to us. ‘All my financial data is in the Cloud. I am less worried about the RTL.’

Related Stories
EDA In The Cloud
Experts at the Table, part 1: While the Cloud may be ready for EDA, it is not clear how ready EDA is for the Cloud. What needs to change?
Verification In The Cloud
Is the semiconductor industry finally ready for EDA as a service?
Follow The Moving Money
How economic considerations are affecting designs at advanced nodes and across geographies.
Which Verification Engine?
Experts at the Table, part 2: The real value of multiple verification engines; cloud-based verification gains some footing, particularly with internal clouds.