As I said on Monday, I am in Japan this week for CDNLive. I haven't been in Japan for business since the year when I was CEO of Envis. Friday it's CDNLive Japan, held in the Yokohama Bay Hotel Tokyo. When I was told the hotel name, I'd never heard of it, but it is the old Pan Pacific Hotel in front of the big Ferris wheel, where I have stayed many times in the past. With the time difference to the US; I am attending CDNLive Japan and then writing about it before everyone wakes up in California. CDNLive Japan I think for the first time, one of the main tracks was simultaneously translated into English (and Japanese for the presentations delivered in English). So the day that I attended included: Opening remarks (T.Kaneko). Lightning Talk by Toshiba on flash memory. Tom Beckley's Keynote (with guest robot Pepper, see the picture). SVG update from Michal Siwiński Brad Griffin with more details of Sigrity 2018, which I already discussed in yesterday's post Sigrity 2018—Into the 3rd Dimensio n. Robert Schweiger on Cadence's automotive solutions (which I like to call CDNDrive) A keynote by Toyota But it is Friday today, and Fridays are cloudy this summer. Luckily, Craig Johnson was also in Yokohama to present Cadence Cloud, so I'll focus on what he talked about. He had a guest presenter too: Dave Pellerin, who is in charge of the semiconductor segment at Amazon Web Servies (AWS). He also talked more about Cadence Orchestrator and characterized a library (okay, just a few cells) using 40 servers on an AWS datacenter in Tokyo. So today I'm going to cover Cadence Cloud, and I'll cover some of the other presentations in a week or two. If you don't read Japanese, I can tell you that the title of this post is Cadence Cloud in Japanese. And if you want to see the above picture with English annotations, then see my original post when we announced Cadence Cloud , which also covers a lot of what Craig talked about in the first part of his presentation. Cadence Cloud Craig covered some of the motivation for Cadence Cloud. I think the attractiveness of cloud-based EDA is pretty much self-evident, so I'll focus on more practical details. The first step is to clarify what you are moving into the cloud for, since that will affect all the other decisions. Motivations include outsourcing a lot of IT, reducing capital expenses, more agility as projects ramp up and down, accelerating tapeout, or to manage some sort of crisis that requires a lot of additional resources. One big decision that needs making at the start is whether to use Passport (where you use the cloud provider as Infrastructure-as-a-Service and do all the tool management yourself) or a Cadence Cloud-Hosted Design Solution (where Cadence manages the EDA environment and the cloud infrastructure for you, and you just have to bring your design). Obviously, if you want to use Palladium in the cloud, then you will go for the Palladium Cloud, you don't really have any choices. I won't discuss that further here, but I covered it last cloudy Friday in my post Palladium Cloud . The next step is to examine the use model. Cadence Cloud can be used for baseline use (that's what you use all the time), for peak use (when in-house resources are insufficient), function-specific (such as only for simulation or library characterization), or some combinations of these. Next, there are decisions to be made about cloud providers. Cadence Cloud almost certainly requires some IP to be in the cloud, and foundry PDK and rule-decks. Once all those boxes are ticked, then a detailed plan can be drawn up. One area where Cadence has made a lot of investment is getting the various tools ready for the cloud. The chart above shows some of the tools, and how scaleable they are. Some now scale to thousands of instances, Amazon Web Services Craig introduced Dave Pellerin of AWS. Dave pointed out that Amazon isn't just a provider of infrastructure in the EDA area, they are a user, too: they design chips and rely on innovation in electronics for their business. As a result, they care deeply about the semiconductor industry and its ecosystem. Dave had a list of what customers are telling AWS are important for next-generation silcon design: Security of IP, workflows, and tools Performance of CPUs Memory performance Network performance Storage performance, including shared file systems Automation and cluster/job management Remote graphics for interactive applications EDA vendor support, including license management Scale, scale, scale In a traditional EDA datacenter, the only certainty is that you always have the wrong number of servers, either too many or too few. Every addtional EDA server than can be brought to bear on the design can improve the speed of innovation if there are not other constraints to scaling. He exorted us to think big: What if you could launch one million verification jobs? Of course, the big gain from a cloud-based solution is the capability to scale fast up (and down) as needs change. AWS operates in a league of its own when it comes to scale—they are bigger than the other cloud providers combined, which means that there are probably financial advantages too. Dave has been working with Cadence. Our engineering organization migrated a lot of regression testing for our tools into the cloud some time ago, and experienced 30X quicker access than waiting for hardware to free up in a datacenter, and 20X faster regressions (since regressions typically consist of thousands of jobs that can be run independently). Dave pointed us to Amazon's white paper Optimizing Electronic Design Automation (EDA) Workflows on AWS . Cadence Orchestrator Craig came back to talk about Cadence Cloud Orchestrator, which is a browser-based cloud-solution. Currently, it is available just for simulation (Xcelium) and library characterization (Liberate). He said that it has not been talked about much in public, but we were going to get the first public demonstration of it running live on an AWS cloud datacenter somewhere in Japan. He showed how to set up using our e-commerce portal EDA-on-tap along with EDACard (which means that you don't have to go through a purchasing cycle each time you want to do this). You then provide your AWS account info, since your cloud resource usage will be billed straight to you without any additional Cadence markup. Then you open up Cloud Orchestrator and use the tools. The demo was based around a hypothetical Japanese company that needed to do some library characterization. An application engineer opened up Orchestrator. There are four functions available: file manager, terminal, X-client, and compute. Terminal opens up a Linux command prompt. The AE ran a script that used 40 licenses of Liberate and specified the type of machine to use. Clicking on "compute" brought up the dashboard and we could see that there were 10 servers in use, each with 4 cores. After a time, the machine count was down to zero, all the results were available, and we could see the start and finish time of each job. As I said above, it is only Liberate and Xcelium today. But we got a sneak preview of running Virtuoso editing an op-amp, which is graphical. To my eyes, it looked just as responsive as Virtuoso normally looks when it is running on the machine you are using, even though it was running on a datacenter somewhere in Japan and only the browser was running locally on the AE's machine. With that, Craig wrapped up with a Japanese phrase he had learned. His slide said "the time is here to design with Cadence Cloud" so I suspect that is what he said in Japanese. Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
↧