Hello Acquired listeners. Today we have with us Rene Haas, the CEO of ARM Holdings. ARM is the company that develops the instruction set architecture and many of the designs underpinning CPUs all over your life today, from our phones to our cars. And Dave and I actually did an episode way back in 2019 on the history of the company, which had a fascinating start out of Cambridge University. The company was publicly traded, then taken private in 2016 by SoftBank, then last year went public again and is now valued at around $150 billion. Rene has quite the career himself in semiconductors. He's been at ARM for the last 11 years and before that was a VP at NVIDIA reporting to Jensen. Rene, welcome to Acquired.
Thank you very much. Pleasure to be here with you both.
Thrilled to have you. Pleasure is all ours. Well, I thought a fun way to start us off since there's a lot of people listening to this that are going to see ARM Holdings and say, 'I know exactly what that is. I know about the strategic shift that they have going on. I've been following every earnings call since they went public.' And there's people that are going to say, 'ARM, what is that?' So maybe to level set everyone on how important ARM is in the world, what are the types of devices where the ARM instruction set architecture and ARM designs are used?
So ARM does CPUs. And what is a CPU? The CPU is the digital brain of every modern electronic device. That is your television set, your thermostat, your car. You were having a chat maybe about talking about a day in the life inside ARM. And I can walk through some of the all the ARM devices inside my home. But simplest way to think about it is we do CPUs and that CPU is the digital brain of every modern electronic device.
And so what is your relationship then with, you know, in my head Apple makes the CPU in my phone, it's the A18 or in my Mac the M4. What do you mean ARM does CPUs?
Yeah. So drilling down one level deeper, we do the design, the ISA, which is the instruction set architecture, and we license that as either an instruction set architecture to a partner. They can develop their own CPU based on ARM. That's what Apple does. Or we design and build our own CPUs and license those CPUs to companies like Samsung, MediaTek, Tesla, Qualcomm, Amazon, etc. So, we deliver it in two different ways, but those CPUs that you mentioned inside your iPhone and inside your MacBook, those are all ARM-based.
And so where we were going with this, I mean today, yeah, if you were to imagine your house, my house, Ben's house, any house, how many devices have an ARM chip in them? And is that a different question than how many ARM chips are floating around my house?
It's a hard question to answer in terms of just how many ARM chips are in my house or how many ARM chips get delivered in terms of a typical application space because it really varies. But again, let's let's go back to first principles, right? ARM designs the CPU and that is the digital brain of every device which means it runs all the complex software that either runs the dashboard or it runs the operating system or it runs an application. So I was thinking about the question and I'm going to drop a bunch of brand names here but let's just kind of walk through. I pull my Audi into the garage. That Audi has ARM processors. Those ARM processors are what you see running the display and that digital dashboard. They're also helping with some of the driver assist and they're probably in the power locks, power windows, etc., etc. I have a Nest doorbell camera that's ARM and that's ARM that basically runs the camera, interfaces with the doorbell, etc., etc. Walking by the LG refrigerator or Wolf stove, I can assure you both of those have ARM inside, too. They're probably running the displays. They're probably running the temperatures and the stove. They're definitely running the display. They're running everything in terms of the oven. Turn on the television set, which is a Samsung. That Samsung digital TV, it's actually running an operating system. So, when you run all those apps and everything that you see kind of shows up on there, that's a version of Android. That's all ARM. Let's say I want to go downstairs and do some gaming. My PS5 has ARM inside, most likely running some of the display controllers and running some of the stuff with a game controller. And if I want to flip through on my Pixel phone, that is ARM inside running Android. And I've got my iPad next to me, that's all ARM. So, you can imagine just about everything that you interacted with that does something that either runs an application, recognizes your face, gives you some display information, ARM did all of that.
I think it's probably true there are hundreds of ARM chips or devices with maybe ARM chips. How would you describe?
There are hundreds of instances of ARM around my house. Probably hundreds. Yeah. Yeah. Probably hundreds. I mean, if you think about the more your home is connected, all those connected things have ARM inside. It's hard to avoid it because you'd almost have to go back to these old mechanical type of controls on machines that actually don't have something that's digital because if it's digital, I can pretty much assure you that it's ARM.
It's pretty wild. So, one stat that I pulled just from your last quarter's financial presentation is that in FY, this is estimated 2024, there's almost 29 billion ARM chips shipped. I mean that is for every human on earth there is four ARM-based chips shipped in the last 12 months. It's a crazy number, right? When you think about the laptop market, which is a big market, right? Everyone wants to ship into laptops, big market, etc., etc. That's 200 million units plus or minus a year, which is a fraction of that 29 billion, right? A very small fraction, very small fraction, right? So, you look at say, well, how is that possible? Because laptop computers, they seem to be, you know, pretty ubiquitous. But just walk through that example I just gave you in terms of those eight or nine examples inside the house and then you start to see well how do you avoid it?
ARM is in an aircraft. You go to an airport and you check in for your flight and you look up at those displays that are listing the gate information and the flight information. That's all ARM-powered that's running that stuff in the background. So it's everywhere and at this point, counterintuitively, it's also in all the cloud architecture that are running the web services that all of these devices are communicating with and that is as we'll get into later in the episode kind of a narrative violation from the way that the world thought about ARM a decade ago versus what is true today.
That's right. I mean the identity of the company we grew up as you mentioned in the opening 30 plus years ago out of Cambridge and the company's original product that we were designed into was the Apple Newton. And for those who may or may not remember that was a PDA before anything had a right to be a PDA before there was the internet before you had voice recognition before you had fingerprint recognition. But the chip that was designed that was based upon ARM inside had two important characteristics. It had to be running off a battery. So as a result, it had to be defined to be low power. And secondly, performance and cost was really important. And back in the day, they used to build chips in two different ways. They had plastic packages, which was pretty rare, and ceramic packages, which were much better in terms of heat dissipation, but were costly and not that great in terms of thermals. So one of the directives in terms of the original design was let's get it in a plastic package. So as a result from the very early days the early ARM processor, the ARM1, that was defined was basically to run off a battery.
Yeah. Which at the time didn't feel as critical to the world since all computers were basically plugged in all the time or most of the computing that people did was at computers that were plugged in all the time and now obviously that's very different.
Absolutely. If I think back in time to the first time that one could take one of those large satellite phones and walk around with them for 20 minutes without having to plug them in, it just seemed like magic. You know, back in the day, if you could get 30 to 40 minutes of battery life off of anything that was doing something sophisticated, it was considered to be just a complete game-changer because mobility was simply not something that was very ubiquitous back in the early days. If I think of stories around this, one of the jobs I had in my career was a field applications engineer, and I'm going to date myself here, but we used to call into the offices for messages. And in fact, we would be driving from account to account. We'd find ourselves, get to a pay phone, but once we got to that pay phone, we could then dial the office. The office would list a whole bunch of messages. The detail of those messages were something like, 'Call me back.' Or, 'I'm not exactly sure what you asked,' or, 'I'm busy.' When we suddenly had a phone in our cars that would allow us to do all these things remotely, we thought, 'Oh my gosh, this is the ultimate productivity gain relative to what seemed like Western Union looking back in terms of making these phone calls back and forth.' But true story, that's exactly how my first field applications job, that's how I used to correspond with a home office.
And so the arc that we're going to keep calling back to over the course of this episode, as you mentioned, the original ARM processor was designed with extreme low heat requirements in mind, kind of low power requirements in order to not quickly drain a battery in a very inefficient world with way fewer advances in lithium ion versus what we have today. And so you sort of think, well, this crappy processor architecture that's extremely limited in its capabilities will never be the dominant architecture used in all of the most sophisticated and advanced computing applications in the world. And yet it is. So over the next hour, we're going to kind of wander through how did we get here? But in Acquired fashion, I want to go way back to the beginning and introduce this idea of the reduced instruction set computer. And I wanted to sort of turn it over to you. You are wildly overqualified to do this as the CEO of ARM, but maybe play computer science professor or computer science history professor with us for a little bit. What was the development of the RISC versus the CISC, the complex instruction set computer, like?
The concepts of RISC and I think they were originally, you know, kind of conceived by professors at University of California Berkeley, David Patterson, and the whole notion around RISC versus CISC was these original processors that were invented and we're going to go way back in time to processor architectures, you know, such as the x86 or the 68000 from Motorola were deemed as CISC processors which stand for, you know, complex instruction set computers which basically meant that they had lots and lots and lots of instructions that they had to carry forward because the software that was written for them prior relied on them. So they were carrying a lot of baggage to do these very complicated instructions which burned a lot of power because the simplest way to think about a CISC implementation is an instruction by its definition because it's complex means it has to run multiple operations from a clock standpoint to execute the instruction which means those transistors are running more than they probably should and you're burning up a bunch of power. By example, in any given clock cycle I need to allow for the possibility of doing something complicated like in this instruction or in this operation, I'm going to go fetch something from memory and load it into a register so that it can be added and I can return the answer all within the same clock cycle. So you sort of have like extra bandwidth everywhere to accommodate doing complicated things in one simple assembly language, you know, line.
Yeah, that's a good way to describe it or another way to think of a complex instruction set. A complex instruction is go three steps forward, two steps to your left, diagonally two steps, right three steps. Now, if you can find an operation that benefits from that specialized activity, that's pretty good. But not a lot of programs can. But once a program has been written and relies on that instruction, then by definition, the architecture has to carry that forward. So you've got all this kind of heavyweight stuff that's involved. So the concepts for RISC were really around simple movements. Move one step forward, one step backward, one step to your left, one step to your right. I'm oversimplifying of course, but these are things like add, subtract, etc., etc. And the idea there being that if you have a simpler set of instructions that can be combined in such a way to be much more efficient, then this is the concept of RISC versus CISC, which gosh, I'm thinking now probably back to the 1980s where MIPS was invented and things of that nature that were the original kind of RISC processors. And this was all around reducing instruction set complexity. But interesting enough that was back in the day when a lot of programs were written on mainframes or minicomputers with previous architectures and it was really interesting if I look back in that time you had a lot of energy being spent on developing new processor techniques when actually you didn't have nearly the mountain of software that you have today. But yes, if you go back in time, RISC was seen as a much more efficient way to do computing. And one of the benefits you had of that was just not only lower power systems, but also going back in time, one of the most more expensive things was actually the memory associated to run all these programs. If you could fit the program in a smaller memory footprint, which again, and with a RISC machine, you can do that, there was some benefit to that. So yeah, that was way, way, way back I would say probably 70s and 80s time frame.
It's so interesting and you can totally see why CISC was conceived of first or at least in the early days believed to be better. It's this really incredibly powerful system where you can any given, you know, instruction can actually do a lot of cool stuff behind the scenes and when you sort of juxtapose it to RISC which in its early days had very few instructions a simple operation would be load, you know, hey go grab this thing from memory put it in a register, oh I can't do anything else that is all we've allowed for in this instruction just load that's it, oops add that's also especially if these larger programs were compiled and then made use of those big instructions from an assembly standpoint because the other thing that was happening was you were having a change from everything being done in what was called low-level programming assembly language to higher level programming models such as FORTRAN, Pascal, and then C and C++ and when you're programming at the higher level languages you have these compilers and then what does the compiler do? The compiler takes that high-level language and tries to put it into lower level language which are what these instructions are. So the compilers end up making use of these heavy instructions and as a result you've just got heavier and more inefficient code and again one of the things that people were trying to do back in the day was get to smaller memory footprints.
Everything you're describing of the old CISC world sounds like you said fits perfectly with the mainframe and the minicomputer era. You know, big iron, big architecture. Nobody's worried about power requirements. Complexity is fine. IBM designs the whole thing. You would think naively that the shift to the PC era would have created the right opening for RISC, but actually CISC continued through the PC era. So like what happened? Was RISC developed just like slightly too late? Did ARM not exist yet? So let's continue down this history lesson here for a moment here.
One of the most amazing things that took place with the IBM PC back in the day was IBM which was the world's leader in computing if you go back in time right if you think about IBM 360 and the IBM mainframes and the IBM minis IBM was a one-stop shop right IBM did the software IBM did the service IBM did the hardware IBM was everything. So now in 1981 IBM decides I'm going to enter the PC market and they were behind. If you go back to the late 70s, early 1980s, Apple has invented the first, you know, end quote home computer based on the Motorola architecture. Then back in the day, you had lots of I wouldn't call them toy computers, but things like TRS-80 and Commodore and they all have these smaller weird little processors into it. So the irony of the whole IBM story was IBM, the behemoth of computing, decides that we're going to now enter into building computers for the home. And what does IBM decide to do? IBM decides to not in-house the processor, nor do they decide to in-house the operating system. They decide that they're going to make this platform end quote open. They need an operating system, DOS, so something that can run off the disc. And they started talking to a company that was actually not Microsoft. Oh yeah. Seattle Computer Products, the classic CP/M-80. They were talking to Gary Kildall and his company about doing that. But they chose Microsoft. And they were also looking at Motorola, which was kind of considered the kingpin at the time to do the processor. But for various different reasons, they decided on Intel and the 8086. The IBM PC is born. And the irony of it is that there's nothing about it that's very IBM-like because it uses external memory, it uses external hard drives, it uses an Intel processor and it uses an operating system from Microsoft. So a little crazy if you kind of look back in time that you'd look at and say why would IBM actually and this is what took off with the birth of all the clones because you could build a clone of that system because if you bought a processor from Intel and you bought a hard drive from Conner or Maxtor or Seagate and you bought a monitor from one of the third parties in Taiwan and you've got a license to do DOS, you're in business and off you go. So to your question though in terms of okay so why didn't somebody do something on RISC there in lies the magic of software compatibility and software legacy because all these early programs it was stuff like Lotus 1-2-3 are now written to run on the x86 processor and optimized on that. So what happened was over the 1980s as the IBM PC compatible market started to take off you had all this software that was written for that platform. And the dirty little secret about CPU architectures and there's been lots of them over the days whether it's again back to SPARC or MIPS or ARC or Tensilica, Tensil where I used to work, 29000, 68000, DEC Alpha, a CPU is only as good as the software that's written on it and how long that software survives. So the IBM PC and its clones ultimately built by companies like Compaq and by Dell and by Gateway and all these other companies that are long gone. Packard if you remember those guys, this is what created the birth of not only the IBM PC platform obviously but the Intel x86 architecture and that's why as a default CISC end quote because that's what x86 was is the de facto. It really wasn't a oh RISC was better because it probably was but kind of didn't matter once IBM selected 8086 and DOS was optimized for that and then subsequently Windows, you know, off it went. Now, the one company was quite interesting that has probably made the most pivots in this area was Apple, right? Because Apple was, you know, originally 68000-based Motorola chip. Yep. And then they created a consortium for the PowerPC. PowerPC, right? With IBM and Motorola, ironically with IBM. With IBM. Yeah, exactly. Which was kind of a RISC hybridy thing. That's very 90s Apple to have something that is like neither RISC nor CISC but entirely reinvented and proprietary. Yeah. And that's what Power was. You know, that was a big switching cost. But I think the other thing that's interesting about that is it was a large switching cost because the amount of software work that was there, but not nearly the amount of software that exists today. I was having a discussion on a podcast that I did with Jensen. Yeah. You guys just launched your own podcast, right? We did. We did. And Jensen made the comment on the podcast that software never dies. That continues to be a very true theme relative to just the amount of heavy lifting required to switch an architecture. But yeah, long-winded answer to your story. If you kind of go back in time, why did CISC kind of make it? It was the IBM PC. And once that took off, that's been a very sticky platform.
That's so funny. Yeah, because RISC was there and arguably would have been better for PCs of like, hey, new paradigm, a lot of new software going to get written. But it was that decision to go with x86 that locked CISC for the PC era. And in CPUs and I would argue for any programmable architecture to get to something that drives a major switching cost, you need a fairly large paradigm shift in terms of benefits on power or benefits on cost. You know, people will talk about you need the 10x advantage to make the switch. I'm not sure it's 10x, but it's not 15%. It's got to be something that's quite material that's going to change in terms of lift and/or it has to drive a level of innovation that could not be done when you're starting out which kind of goes all the way back to the Newton. There was no way that an x86 could have been an option. You simply could not build the product. You either have to start in a space where something is very new and you need some very unique computing paradigm and/or you've got to drive some different level of innovation to quantify the if it's not 10x what is it? I bet if you just go look at the Geekbench scores from whatever Apple's latest and greatest Intel-based MacBook Pros were before switching to the M1 that's probably the exact quantification of how much better does something need to be to stay in an existing paradigm and switch from one horse to another.
Huh. We want to thank our longtime friend of the show, Vanta, the leading trust management platform. Vanta, of course, automates your security reviews and compliance efforts. So, frameworks like SOC 2, ISO 27001, GDPR, and HIPAA compliance and monitoring. Vanta takes care of these otherwise incredibly time and resource draining efforts for your organization and makes them fast and simple. Yep. Vanta is the perfect example of the quote that we talk about all the time here on Acquired. Jeff Bezos's idea that a company should only focus on what actually makes your beer taste better, i.e. spend your time and resources only on what's actually going to move the needle for your product and your customers and outsource everything else that doesn't. Every company needs compliance and trust with their vendors and customers. It plays a major role in enabling revenue because customers and partners demand it, but yet it adds zero flavor to your actual product. Vanta takes care of all of it for you. No more spreadsheets, no fragmented tools, no manual reviews to cobble together your security and compliance requirements. It is one single software pane of glass that connects to all of your services via APIs and eliminates countless hours of work for your organization. There are now AI capabilities to make this even more powerful. And they even integrate with over 300 external tools. Plus, they let customers build private integrations with their internal systems. And perhaps most importantly, your security reviews are now real time instead of static. So you can monitor and share with your customers and partners to give them added confidence. So whether you're a startup or a large enterprise and your company is ready to automate compliance and streamline security reviews like Vanta's 7,000 customers around the globe and go back to making your beer taste better. Head on over to vanta.com/acquired and just tell them that Ben and David sent you. And thanks to friend of the show Christina, Vanta CEO, all Acquired listeners get $1,000 of free credit. vanta.com/acquired.
Okay, so we've perfectly set the table for CISC in the PC era, pretty locked in, not going anywhere. ARM is founded. It's using a RISC-based approach. What is ARM doing for its first couple decades in existence? What markets does it serve?
So go back to kind of the invention of ARM and one of the unique things that ARM drove also back in the day that I think couldn't be done today, but perfect time, perfect place, perfect strategy, all of this is also luck and timing. All of those processors that I just described to you, x86, 68000, AMD 29000, the list goes on, they were all vertically integrated. And believe it or not, a lot of people used to spend a lot of time designing their own microprocessors. And ARM had an idea that that's a lot of work. That's a lot of effort. There's not a lot of differentiation that one microprocessor can have versus another microprocessor. So why don't we come up with a business model that rather than building our own and trying to enter the market against what is very crowded, I'm going to license it and I'm going to make it available to companies rather than developing their own just run on ARM. And I'm going to license it. I'm not going to charge, no pun intended, an arm and a leg for it. I'm going to have a business model that's going to require an upfront licensing fee, which is modest, and I'll take a royalty when you ship in production. And the idea back then was on a shared success model, which I think again back to the founders, you know, back to people like Robin Saxby and Tudor Brown. That was really a rather brilliant idea because the notion was pay me an upfront license fee, which is kind of a proxy for R&D. In other words, you're not going to spend the money on the engineers anymore to do the development. The licensing fee will be sort of a proxy for R&D. So, it's not an exorbitant fee. And more importantly, it's not money you wouldn't be spending anyway. So, by licensing the technology, you're not going to need to hire the engineers to develop the product because I've already done that for you. And then on the back end, if you ship a whole bunch of products, which is good for you, then pay me a percentage of it because it's good for me, too. So, it's a shared success model. You look back and say, 'Wow, brilliant. Of course, why wouldn't everybody do that?' But back when ARM started in the early 1990s, one of the things that was really not there yet was all of the tools and methodologies and flows needed in the ecosystem to make it work. Synopsys and high-level design language pretty new, Cadence doing back-end design where you could just take someone else's design and integrate it into an overall flow pretty new, a set of software tools that was involved, you all pretty new. So ARM was really driving a lot of innovation and because we were so new, you know, again going back to the superpower of a CPU was really the software, we had no software. There were no application ecosystem that ran on ARM, there weren't operating systems that ran on ARM. So it was very difficult in the early days to get some stickiness from a software standpoint. So our very first design win that kind of made the company and it's again it's a classic story of accidental empires where right time, right place, but now mobile phones are taking off in the mid-1990s and Texas Instruments is one of the largest suppliers of baseband chips for 2G phones and GSM phones and what they needed inside the phone was a small microprocessor that could help the baseband machine on. So the idea of the processor was not to run any kind of applications because back in the 1990s there were no applications that ran on a GSM phone. The application was the phone. The application was the phone, right? So the customer was TI, but the big customer was Nokia. It was the first Nokia GSM phones that used a TI chip that had an ARM CPU inside. And TI chose ARM because they looked around everything they had and they didn't really have anything that was as elegant as ARM and they thought well why would I design my own CPU because the value back then with TI's product was in the radio wasn't really in the processor. Every company if you look back in the chip world has a design that was the market maker for them. That was it for us.
It really reminds me of the TSMC story and journey just, you know, a couple years later, right, of like starting with like, okay, we're going to take a layer of the stack here, you know, them at the most lowest level layer of production and you guys one layer up from that and we're going to make it available to all these people who want chips, but like we're not going after the PC market. We're not going after, you know, anything big that's going to be what it is today. Oh, we'll start with this small stuff and applications like these TI CPUs in a component not leading edge in the fab terms. Great. We'll take that. And it's just amazing over the next 20, 30 years how far it's come. And it's the same echo of the Windows story, which is it's fine to not make that much money early on, but once everyone standardizes on you, you have a lot of power in a market.
Well, exactly right. Once we found our way into the TI handset chipset that went into Nokia phone, now we have traction and now other folks who are trying to build baseband chips for GSM phones, ARM becomes the de facto standard. Not so much quite frankly because we ran any operating system or we ran any apps because there were none. It was just simply, hey, it works pretty well. It's got the right power, it's got the right performance and off you go which is a lot of ways, you know, designs ultimately sort of take off. So then you get into well what was the lift if you will underneath the wings of the architecture. Well fast forward these GSM phones got a little bit smarter and they began to run an operating system called Symbian. So we actually began to have some level of stickiness in terms of there was a software community and development ecosystem that started to learn and run on ARM. But I would say if I was to look back and say, well, what was the design that took ARM completely into the next level? It was the iPhone. If you look back at the iPhone, because ARM now had some street cred, if you will, in terms of low power, and we had street cred in terms of we could run small operating systems and small applications. We were chosen as the engine inside the first iPod.
Oh, I didn't realize that. Yeah.
So if you go back to early 2000s when the first iPod came out. Yeah. Those early little Toshiba hard drives that kind of had no other use case except for... That's right. So if you remember that iPod, right, that iPod had a kind of a crude display and it would have, you know, it had an operating system. Had a little operating system. It had a thumb wheel. So you had a UI. It had all the things of a tiny little computer. The iPod was based on ARM. So fast forward now this is early 2000s. As the 2000s are moving forward and Apple starts to fuss around with are we going to build a phone? Are we going to build an iPad and revisionist history, you know, there's all kinds of stories which one they were going to build first, but it's probably less important in that they had a decision to make in terms of what was the processor going to be inside the iPhone. Industry, you know, legend is that they did talk to Intel about using Intel and Intel's processor of choice back then was something called the Atom, which was their low power or attempted low power device. Respectfully, it was not really so low power and it was not really so low cost. It was kind of a very stripped down x86 and they were building gosh all this history. I'm kind of going back in time here. You guys probably remember a product called a netbook. Oh yes, of course. The PC industry was lined up that netbooks were the future and that was just flat-out wrong. Exactly. Well, it was right until the iPhone. It was right until the iPhone and Atom was the chip inside the netbook. Intel was coming from a very lofty place of selling, you know, very high performance and very good Core i7s, Core i5s. The Atom, you know, this is the classic innovator's dilemma, right? You know, innovate from the bottom versus the top. Intel was having to come all the way down from i7, i5, i3, Pentium, Celeron down to a little itty bitty Atom, which was designed for the netbook and was probably okay for a stripped down low power netbook, a laptop, excuse me. But for a phone that needs to run at even more low, not great, right? But Intel has got all of the street cred inside of Apple at the time because they've made that transition by now away from Power to x86. So all the laptops inside of Apple are all running on x86, which is on its own a miracle. Like they changed a compiler to make it so that applications written targeting a Power platform, the Power architecture could suddenly now with some changes compile to Intel. Oh my god, that is a compiler miracle. Massive amount of work, years and years of work by Apple. So you can imagine the debates inside of Apple in 2006, 2007 and the stated goal for the operating system whether, you know, phone, tablet, whatever it was supposed to be initially, but was basically run OS X or a version of it on a mobile device and OS X ran on Intel at that point.
Yeah, you guys are bringing back all kinds of stuff that I completely thought I had forgotten in my memory is there's a whole different exercise here on how neural nets work because you guys are uncovering all this other stuff. But you had operating systems like Leopard and Snow Leopard and all these things that were pretty powerful hefty operating systems, right? They're running all on x86. So Intel and Apple have made the shift now in the mid-2000s away from Power into Intel. You have all this investment that's been made on these Mac operating systems, as I mentioned, all of these Tigers and Leopards that are all optimized to Intel. You have a big franchise inside of Apple that is all based on Intel and the Mac operating system. And then you've got this little fuddy little iPod that runs on ARM with a kind of a crude display, which is basically an embedded system. So, you can imagine that an easy choice would be we're going to build this on Atom and we're going to have the operating system of Mac OS and this new thing look the same because software will be easier. We'll strip it down and we'll just basically take our laptop and our desktop operating system, strip it down to the phone and run it on Intel. Or we can build up from this iPod, use ARM and build something called iOS, which is the operating system for the phone. And it's going to be different than the Mac OS. But you know what? This market is very different. It's going to require a different level of efficiency, different level of power. If we clean sheet it and do it right this way, or the bias was at the time from the iPod team was this is the right way to do it, we'll end up with a better product at the end of the day. So that was the debate inside and ultimately the iPod team won.
Sort of, right? Didn't they kind of split the baby where it was an ARM processor but it was a version of Mac OS's kernel that had a new compiler written to target ARM instead of... Oh yeah, yeah, yeah, for sure. But you know they didn't start from scratch but yes they started cutting things down and to simplify it and build it up but yes that was the key design win for us. Once that happened then very quickly you had followers from the Android ecosystem, the Samsungs of the world and if you go back in time, companies like HTC as Andy Rubin and Android started to take off now ARM was seen as the de facto standard and you had a lot of work that was already now being done around Linux and such. So we had the one-two punch of having the iPhone and ultimately the Android ecosystem designing around ARM and this is 2007, 2008 time frame.
And at this point in time just so listeners can kind of anchor on what ingredient to the stew does ARM provide? They were standardizing Apple and these Android vendors on ARM as the instruction set architecture. Who was actually making the processor in the first iPhone or in these other Android phones? If 1981 is 2007, ARM is Intel. Except the benefit that ARM has is that instead of Intel being Intel, in other words, Intel builds the x86 and owns the architecture, ARM is licensing the architecture to companies like Samsung. To your question, if you go all the way back in time, believe it or not, that first iPhone chip, I think, was built by Samsung for Apple. And then ultimately, I think Apple went to TSMC. The chip...
Vendors back in the day are companies like Samsung, Qualcomm, believe it or not, Nvidia. The Tegra stuff was all ARM-based. So, it was crowded. And why not? You have this smartphone market that's now starting to take off. And chip vendors now have an opportunity to build chips for these phones based on ARM. And again, if I do my IBM PC parallel, it would have been as if Intel would have licensed x86 and they did to one guy AMD because they were forced to. And this is kind of interesting if you just do the parallels because IBM was so worried about multiple sourcing because the x86 was such a critical part is that they exercise and I think I have this right to work on a second source for x86. So what you had with ARM was multiple sources. So you can see why the business model suddenly became very powerful because now to your point what did we provide in the stew kind of whatever the most basic ingredient is in stew. I don't like stew personally so I don't know what the best ingredient is but let's assume it's water that without water you have nothing. We supplied the water. There was no way anybody could do anything to enter the smartphone market unless you went through ARM and there's an element of portability. It's beautiful if you're Apple and you want to design the next version of your phone you're thinking well there are a bunch of ARM-based processors out there. So as long as we pick ARM, we have this whole different sea of vendors, including eventually ourselves after we acquire PA Semi that we can sort of pick as our chip vendor.
That's right. So they can either pick companies that build ARM chips or if they're brave enough and talented enough and smart enough, ARM will give you the rights to build an ARM-compatible chip yourself. So rather than licensing it from or buying the chip from Samsung who used one of our designs, you can just go build your own, which is what Apple did.
All right. So now that we're in these early 2010s period, this is probably a good place to explain the dual ARM business models. So at least at that point in history, how does ARM make money? So, back to the simple concept of licensing and royalties. Our business model way back in the day, and it still pretty much holds, is that we have an upfront fee for licensing and royalties. As you can imagine, when you're starting out, and a lot of companies aren't actually shipping any volume. The vast majority of your revenues come from licensing, and the proxy for that in the chip world is design wins. So, you get a lot of design wins. You get people committed to the architecture, but they don't actually ship any volume. So, you don't really get to a mix of royalties until you're in volume. So, it took a long time, but licensing was bigger than royalties for many years. And you could look at that glass half full and say, 'Wow, the future is going to be bright if you ever get there.' Glass half empty would be, 'Hey, this stuff doesn't work.' Well, I'm betting on the front end. And are these things ever going to see the light of day? Now one thing that we changed, I wouldn't say changed but another version of the business model is the license. You can either license a core that we built, we call that an implementation, that is we basically do the blueprint and says the house looks like this and you let this means in-house you have your own chip designers they're using Cadence and Synopsys and their floor planning and they're actually, you know, they're doing what everyone sort of imagines Nvidia is doing over there.
There were a set of customers that believed that either due to the link between hardware and software or the ability of their engineers to develop something that would be higher performance than what we could build. We had these architectural licenses and it allowed customers to build their own implementation. Now, one of the things that sometimes gets confused about these licenses is that are they able to run software that's not ARM compliant? In other words, can they add some special instructions that nobody else has which gives them a unique advantage? And they're not allowed to do that. And the reason is very, very simple. Once instructions look different across a number of different architectures that a customer has, software can't understand it. And let me drill on that a little bit further. If customer A has an instruction that says accelerate and customer B has an instruction that says accelerate 2X and customer three has an instruction that says accelerate 3X. If I'm a software developer and I'm writing software for ARM, I really don't have my program taking advantage of the 3x instruction because I don't know that everybody has it. So I end up going to something we kind of call inside as a lowest common denominator approach that the software developer would not make use of those instructions. So it's one of the great things the company has done in its early days and we've maintained it certainly since I've been running it. We're never going to break the ISA. We're not going to allow people to add custom instructions because once you do that you break software compatibility which is one of the superpowers of ARM. And if you think about, you know, why did x86 stay so sticky on the IBM PC? It's because Intel was the only game in town. So, of course, they were going to run. And that's why Compaq and Dell and all these other clone guys were able to copy the PC because the software just ran. And if they were not able to do it in such a way that IBM did it, they could never be successful. So, we offer these licenses, they're architectural licenses, but all they really do is allow people to build their own implementations. And I will say just adding on to that, I know we're going back and forth between the future and the past. We used to do a lot of them because customers used to believe that a they could build a better design than ARM and or b there was something specific in the software they want to take advantage of. Not many people do them anymore. They're really hard and back to the 10 to 15% advantage or even 5% advantage. The ROI isn't all that high. And if you're going to have three or four engineers designing an ARM CPU that you can buy from ARM anyway, why not take those three or 400 engineers and put them on IP that you do as a customer that only you do? Nobody's building a CPU with three or four engineers, right? It's three or 400 or thousand.
Yeah. Three or 400. Yeah. No, not three or four. If I said three or four, that's a big win. Yeah. Three or 400 at least. It's a lot of work. It's hard.
Well, and I imagine for probably almost every customer out there now, the ecosystem and compatibility of software across all vendors, you know, all applications out there is worth so much that it, you know, they wouldn't even consider going out and altering the instruction set, right? Because then they would lose compatibility with the rest of the ecosystem. And I know we're hopping around, you know, in terms of history dates, but that's one of the things that I think gets lost in terms of what's gone on with CPUs and software compatibility over the last 15, 20 years because as we were talking about the 1980s, early 1990s, I mentioned a lot of microprocessors, right? The 68000, PowerPC, 29000, DEC Alpha, SPARC. There's a pretty large graveyard of CPUs and they were very good products. Very, very good in terms of performance, very, very good in terms of their design and they've just entered the graveyard of CPUs and you say yourself well why do they all die off? Well once the flywheel of software gets built onto a certain architecture it's very, very difficult for if you're developing a new piece of hardware to say well I'll choose one of the ones I just mentioned because there really isn't a software story around it so they all began to wither away once the internet took off and particularly as you got into the dot-com era and a little bit after it, huge amounts of investment started to go into software companies and software as a service, subscriptions, SaaS models, recurring revenue, everything around the software industry, which was wonderful. Two things happened with that. Number one, it drove an increased innovation and investment into software and all levels of software, the complexity of software. Software stacks that run the cloud, that run in a network switch, that run in an automobile. And at the same time, semiconductor investments, which is changing a little bit now, began to wane and very little venture money started to go into startups and semiconductor startups in particular.
