Everyone in EDA is familiar with the phenomenon where the internal testing of a tool all goes perfectly, the initial customer checkout flights of the tool go well. Then when that same customer starts to use the tool for real, on a real design, all sorts of issues emerge. This problem is not restricted to EDA. In technology in general, it is only when a product is used for mission-critical purposes that it truly gets shaken down. One solution to this conundrum, when it is applicable, is for the company developing the product to use it for their own development. The somewhat unusual phrase for this is "eating your own dogfood." It even has its own Wikipedia page . The most likely source of the term is from TV ads in the 1970s for Alpo, when actor Lorne Greene said that he fed Alpo to his own dogs. A couple of years ago, Simon Segars told me (see my post The Design That Made Arm ) that he'd told his IT department to get their own website arm.com running on Arm servers. Of course, starting to eat their own dogfood led to predictable results. There were a lot of pieces of the puzzle missing to do a real-world full deployment of software in live datacenter, a lot more than just bringing up Linux (for that topic, see my post about Red Hat How Arm Servers Can Take Over the World ). Late last year, Cadence announced Xcelium simulation running on Arm servers (see my post cleverly titled Xcelium Simulation Running on Arm Servers ). Qualcomm is one of the companies that builds the Arm server chips. Qualcomm does a lot of Xcelium simulation. The obvious thing to do is to eat their own dogfood and deploy Arm servers to their simulation farms. When I said the phrase "eat your own dogfood" to Qualcomm's Kathy Herring Hayashi in the expo at CDNLive, she said that Qualcomm prefers the phrase "drink your own champagne." In fact, she is the head of the Champage project to knock down all the obstacles and bring up Arm servers in some of their compute farms. One big attraction for Qualcomm is that their datacenters are out of power, not space, and the Arm servers are much lower power. Arm's Tim Thornton is in a similar job role as part of their engineering IT organization, bringing up Arm-based servers for deployment to Arm's engineering teams. The picture above shows the two of them with an Arm server. The Centriq 2400 chip (there are two) contains a custom-built CPU with 48 cores and lower power consumption than a similar x86 server. It's manufactured in 10nm, and runs at 2.6 GHz. That's the chip on the right, although in normal use it would have a heatsink on it (hey, Arm is low power, but not so low power that you can run 48 server-grade cores without a heatsink and fans). If you look closely at the picture, another thing that you would normally find would be some memory in those DIMM slots. Presentation Later in the afternoon, Kathy and Tim gave their CDNLive presentation Introducing Next-Generation Engineering Compute: Building the EDA Stack on Arm . I see that the Arm part was officially called On Arm, At Arm although the overall title covers both parts of the presentation well. They said that their mission is to "make Arm servers boring" from an operational perspective. In general, the design and verification engineers kicking off the jobs (or queueing them up in LSF or another dispatcher) shouldn't even be aware of which processor architecture is running their job. Qualcomm currently has a set up with 15 servers, supplying over 800 cores, and all the other expected datacenter stuff (like networking and storage). They started with compute-intensive high-volume jobs as the initial deployment, and that meant Xcelium. Using Xcelium on Arm will give identical results to using it on x86. In fact, one of the ways that they test this is to run the full verification suite for an Arm core and then diff all the output files. They should be identical down to the individual characters (except for obvious things like the time of day, or the runtime). Another important point is that x86 and Arm implementations of Xcelium are built off the same code base—this is something that is built to scale for the long term. Tim said they run Red Hat's Enterprise Linux. They use Foreman , Ansible , and Puppet to deploy the platform and provision the servers. If you are in datacenter operations I assume these products are well-known, but I'm not a datacenter operations manager (I don't even play one on TV), but I found the links to make sure I got the names correct. The plan is to continue past Xcelium to other high-volume jobs, such as cell-library characterization. But eventually, everything will run on Arm identically to x86. The one wrinkle is anything to do with user object code, which means that the most advanced save and restore in Xcelium, known as checkpointing, has a restriction. In the Q&A, Adam Sherer, the marketing manager for Xcelium, said that a checkpoint can only be restarted on the same architecture because it saves the state of your C/C++ external modules, not just the state of the simulation. Arm is also working with Qualcomm on a Windows machine, so you will be able to unfold your Arms out of the datacenter and onto the desktop too. The attraction is the lower total cost of ownership (TCO): lower hardware cost, higher density, reduced power, increase throughput. For a given "size" of datacenter, you get more compute power using Arm servers. Since this is all about Champagne, here is that sentence in bubbles: Server Availability There will be platforms from multiple vendors coming to market in the next few months so that time is ripe to look at how your infrastructure might look with Arm a part of it. I'm not quite sure where you will buy them, so I'll just say the equivalent of "wherever you get your podcasts." You will soon be able to get them wherever you buy your servers. And if your name is Tim Cook and you want to buy a whole datacenter's worth, I'm sure I can find out Steve Mollenkopf's phone number. Looping back to where we came in, he gave the keynote at CDNLive a couple of years ago (see my post Qualcomm Looks to the Future: Steve Mollenkopf's CDNLive Keynote ). Sign up for Sunday Brunch, the weekly Breakfast Bytes email![]()
↧