Liberate Trio on AWS/Graviton2 Instances

This is a sort of continuation of yesterday's post JAWS: JasperGold in the AWS Cloud. It takes a look at the use of the Liberate Trio Characterization Suite on AWS, but this time on Arm-based Graviton2 instances. There was a recent Cadence/Arm CadenceCONNECT event, Building Arm Compute with Cadence Digital Full Flow for Best PPA, which you can read about in my post Arm/Cadence on Implementing Advanced Microprocessors in Advanced Processes. The final presentation was by Arm's Ajay Chopra and Cadence's Praveen Patel with the factually accurate but unwieldy title Cloud-Based Characterization with Cadence Liberate Trio Characterization Suite and Amazon EC2 M6g Instances Powered by Arm-based AWS Graviton2. For an introduction to Cadence's Liberate Trio product, see my post Liberate Trio: Characterization Suite in the Cloud.

This was actually a sort of update on a presentation from 2019 on doing library characterization on Graviton (or what we now call Graviton1). You can read about that in the second half of my post EDA in the Cloud: Astera Labs, AWS, Arm, and Cadence Report. The overview of what is in that earlier presentation is that Arm was doing standard-cell library characterization with Liberate Trio on as many as 50,000 Graviton cores (yes, really).

One paragraph from that earlier blog post:

Characterization is, in some ways, ideal for scaling into the cloud. A cell-library contains hundreds of cells, perhaps thousands. These all have to be characterized at dozens or even hundreds of process corners (different process corner, supply voltage, and temperature). The computationally expensive part of the process is running circuit simulation for each cell-corner combination. However, there is no connection between one simulation and another,  they do not have to synchronize with each other. This means that characterization scales linearly up to 50,000 CPUs.

Obviously, on Graviton2, they got improved results.

Switching from 4K slots to 20K slots reduced Arm's time to characterize the library from four months to one month. It also caused a qualitative shift from being computer-limited to being human-limited. This is because there is virtually no waiting for jobs to complete, and engineers are never (what never, well hardly ever) waiting for results from the servers.

With the obvious caveat of using the products wisely, Liberate Trio on AWS Cloud using Graviton2-based servers reduces costs by over half, runtime by around a third, and obviously reduces overall turnaround time.

Later in the presentation, Ajay went into a lot of detail on costs and performance of various kinds of AWS cores, spot pricing versus on-demand pricing, and so on. A lot of this was already covered in my early post about using Liberate Trio on AWS, and only instance names have changed, along with the performance numbers. Here's a summary slide. To understand it, you need to remember that x86 is dual-threaded and Arm is not. As a result, a physical x86 core can run two jobs where Arm does not. By the way, m6g is AWS jargon for a Graviton2 instance. So when you compare, you need to distinguish physical cores, threads, overall throughput, and be clear about what cost you are comparing. To add to complexity, costs vary by AWS physical region since they depend on demand. 

Bottom line, a 42-56% cost reduction despite the slowdown (due to threads per physical core going from 2 to 1).

There were no practical problems scaling. The blue line in the above graph is the number of jobs running, the red line the number of m6g slots being used. This was not the biggest of libraries so they scaled up to "only" 12,000 m6g servers.

Learn More

More information on the Liberate Trio Characterization Suite is available on the Liberate Trio webpage.

Or watch the video:

 

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.