I'm Nandan Nayampally, the Vice President of Product Marketing in Arm's CPU Group. Thank you all for joining this presentation. For the next 30 minutes or so, I will talk you through some of the features and key benefits of Arm's Armv8-A processor architecture. The lagging A in Armv8-A refers to application processors, which indicates that these processors will be able to run large operating systems like Linux, Windows, and platforms like Android. The Cortex-A50 Series of processors is the first Arm CPUs that are based on the Armv8-A architecture. As you may recall, in October, we also announced an Armv8-R architecture for real-time environments like automotive, industrial, and storage. However, products based on this architecture will be a while in coming.
I will start by giving some insight into how Arm goes about developing an architecture and the thought process that drove the Armv8-A specification in particular. I will then have a look at some of the technical features that we've introduced in the Armv8-A and the new use cases that are enabled for new users. Finally, I will look at how Armv8-A ecosystem is expanding today and where we, as our partnership, see the opportunity. Before we jump into some of our technical aspects of Armv8-A, let's get some market context. More and more people are using their preferred mobile devices, smartphones, tablets, and more as their primary computers. In developed countries, people expect to get a desktop-like performance from a small battery-powered device.
In developing countries, the mobile revolution has introduced computers and the freedom of the internet to people who had never even seen a desktop before. Arm has been at the heart of this revolution, enabling a wave of innovation from silicon partners, OEMs, and software developers alike. Increasingly, users in the networking and server space have been calling for similar waves of innovation to help them meet the ever-growing demand for cloud-based services and mobile video while continually reducing cost and power. In order to meet these bold growth projections, our partners need a future-proof platform for developing the computer systems of tomorrow. Armv8-A is that platform, and its development is one of the largest projects ever undertaken at Arm. Let's take some time to familiarize ourselves with the terms we will be using. The first term, obviously, is architecture. Architecture is the contract between hardware and software.
It is much more than just the instruction set, which is what it often gets confused with. An architecture confers rights and responsibilities to both the hardware and the software. It includes specifications for things like debug, monitoring, and more. The formal architecture description is extremely detailed. In Armv8's case, it went over 5,000 pages. This architecture specification is also a guideline for software and OS developers on how to design their software for the CPUs that are built around this architecture. Processor microarchitectures are actual hardware designed to conform to the architecture specification we just used. These processors may target different performance and power sweet spots, different cost points.
For example, the Cortex-A53 and the Cortex-A57 processor cores are designed for different markets, different performance targets, different power targets, but both comply with the Armv8-A architecture, and the software written for one of these processors will run on the other. Arm not only licenses its customers these processor products, but in certain cases, customers choose to license the architecture specification itself and build their own processor designs to conform to it. Nvidia's Denver and AppliedMicro's X-Gene processors are in-house designs that conform to the Armv8-A architecture spec. Arm does provide an executable specification that ensures strict compliance with the architecture. This has been one of the key reasons why the Arm ecosystem has been growing robustly as software designed for one set of processors works on any other Arm processor that has the same architecture.
In summary, the architecture defines what a processor should do and how it should run standard software. A processor chooses the right trade-off points for performance, power, and potentially optional feature sets that are demanded by its target market. Now for a bit of history. The first ARM1 chip, the ARM1, was built by Acorn in 1985, a chip that ran at 8 megahertz, fitted with 4 megabytes of RAM and powered the popular BBC Micro. In 1990, Arm was spun out of Acorn as an independent company, and by the time Arm listed as a public company in 1998, the architecture had evolved to ARMv4, which introduced Thumb instruction set and was a part of the iconic ARM7TDMI processor that fueled the early digital mobile phones.
In the 15 years since 1998, Arm has released four new architectures, each of these introduced with additional features that the market critically needed and continued performance enhancements, along with the continued efficiency improvements. Of course, with increased complexity comes increased engineering effort. The original ARM1 chip contained 25,000 transistors and was designed by a team of five engineers. Today, a leading-edge system on a chip might contain 1 billion transistors, and Arm processors within those chips are a result of hundreds of man-years of work. Arm's unique business model has allowed silicon vendors and OEMs to bring their own innovations to systems on chip built around efficient processors with a thriving ecosystem, enabling a staggering advance in the capabilities of these mobile devices. When defining a new architecture, we need to plan a long way forward.
Decisions made at the outset of the project will impact the work of OEMs, software architecture, and development for 20 years or more, so it is important to get every detail right. The team of engineers at Arm's architecture group started to define the Armv8-A architecture in 2007, nearly seven years ago. Once the specification was finalized, Arm CPU engineers commenced the design of the Cortex-A53 and A57 processors. These processors were licensed to our lead customers around two years ago, and the first Cortex-A53 chips from our partners will be available soon this year. There is no doubt that the Armv8-A architecture licensing got off to a very strong start, but there is plenty more to come. So far, we have developed two Cortex-A products for the Armv8-A architecture and signed 30 licenses with 20 companies.
In comparison, the Armv7-A architecture, we have released 7 processor or CPU designs and signed over 130 licenses with over 80 companies. As the Armv8-A technology matures, it will be marketed to a wider area of semiconductor companies. It is reasonable to assume that Arm will continue to innovate around the architecture, bringing more licensing opportunities in the future. Going back to the example set by the Armv7-A, we licensed our first processor from that architecture in 2003, and in 2014, we released the latest version of the Armv7-A processor, the Cortex-A17. We expect there to be a market for Armv7-A and Armv8-A processors for many years to come. Let's cast our minds back to 2007, when work commenced on the Armv8-A. The smartphone revolution had just begun, but the early devices cost over GBP 600 and were used exclusively by the wealthy.
In contrast, billions of people in low-income economies were using voice-only phones based on the ARMv4 architecture. One of the key goals of Armv8-A was that it should be making more advanced computing affordable to all. We wanted to see Armv8-A processors in GBP 60 phones, not just GBP 600 phones. That way, developers would be able to target billions of end users with a single unified OS. At the same time, we could see that the consumers would come to use these mobile devices as their main computer. We looked at the trend in desktop software, where modern APIs rely on vast memory spaces. We looked at the increased consumption of video and rapid growth in cloud services like Facebook. Those cloud services present opportunities outside of mobile.
Network traffic was growing exponentially, the data center operators were pushing for more efficient hardware, both from a power and a cost point of view. These trends suggested a need for expanded multimedia capabilities, enhanced security, and 64-bit memory support. Historically, processor architectures, as they've moved to support 64-bit, took one of two directions. They either created a brand-new architecture excluding any efficient legacy mode, or they added 64-bit to an existing 32-bit architecture, which drove up decoding complexity and other inefficiencies. The mandate for the Armv8-A architects was to provide full backward compatibility to existing 32-bit software while providing a 64-bit capability. However, the architect's challenge was to design something that would maximize the power efficiency for both types of software, as the goal was to go into cost-effective mobile devices in the long term. Sometimes having a chance to review pitfalls provides new insights.
To solve this, Armv8-A has two processor states: AArch32 and AArch64. AArch32 supports all 32-bit legacy Arm software. It streamlines the existing 32-bit Armv7-A architecture and adds new capability and instructions for cryptography and to improve efficiencies in concurrent programming. AArch64 is a brand-new instruction set. 64-bit allows the processor to address larger chunks of data from memory. The benefit of 64-bit shows when dealing with sophisticated applications and large file systems. This allows for faster data manipulation on personal devices and cloud-based platforms. It also introduces an advanced vector mathematics capability for compute-intensive activities. The coexistence of AArch32 and AArch64 processor states allows an Armv8 architecture processor to run both 32-bit apps or 64-bit apps on the same OS. This architecture allows for efficient reuse of hardware within the CPU, such as register spaces and data paths between the two states.
The incremental size increase, therefore, between a 32-bit processor and 64 processor, is only the order of 10%. How did we design Armv8 for efficiency? As you might expect from a modern architecture, Armv8 is designed to continue to support efficient virtualization, TrustZone security, and the other key benefits of the Armv7-A architecture. To extend this, we also introduced new cryptography instructions that speed up encryption software routines for AES and Secure Hash by nearly 10 times. This makes it a lot more efficient to bolster consumer privacy and enterprise security on the hardware itself. Additionally, in Arm's architecture, what the software community calls the memory ordering model is designed for low-power operation. In Armv8-A, across both 32-bit and 64-bit states, we've added instructions that enhance efficient synchronization across different software threads. This makes concurrent programming simpler from a software programmer's view, and multiprocessing operations become more efficient.
This is a major benefit for today's consumer devices that use quad and octa-core processing solutions. In the AArch64 state, we took the opportunity to extend, expand, and simplify the architectural registers. Arm's Neon technology accelerates multimedia and signal processing algorithms such as video encode, decode, 2D and 3D graphics, gaming, audio, speech processing, and some levels of image processing. Armv8 doubles the number and the size of the Neon registers, in effect, offering improved performance of audio and video processing and other vectorizable computation. This is very important for new areas like HPC or high-performance computing. Putting it all together, we get a basis for platforms that can scale across everything from low-cost phones to secure high-end mobile devices that deliver desktop-class performance while fitting in your pocket. Armv8 processors today deliver more performance on existing 32-bit software.
With the 64-bit state, we allow the processors to address more memory. We will see consumer devices with 4 to 16 gigabytes of RAM in the near future, and enterprises devices with terabytes. We focus on running this more complex software stack and more complex application profile while consuming lower power. This enables more interactive graphical and computationally intensive software run on very compact mobile platforms. We will see more gesture recognition, face recognition, advanced voice control, augmented reality, and more. The leading driver, of course, for 64-bit is the console quality game that is very attractive in phones today. Even today's phones, which use 32-bit Arm processors, are increasingly seeing these console quality games, and Arm's technology, such as big.LITTLE, allows this to fit into the thermal profile of a handheld device, maintain battery life, while giving the user the experience that they're looking for.
With Armv8-A, we extend this benefit to make that more efficient, more capable, and more engaging. Armv8-A offers a platform that can deliver a very wide performance range from clamshell large-screen devices to entry-level smartphones built on a common, efficient OS image. Application developers can target a single platform and deliver applications across these various form factors of devices. One of the biggest problems facing mobile devices today is how to separate and protect and secure the private and public data that we all use. Arm foresaw this over a decade ago and has been progressively building technology into the Arm architecture over this period. In the late stages of the Armv6 architecture, with the ARM1176 processor in the year 2003, we introduced TrustZone as a mechanism to put the root of trust in hardware.
While it started off as a SIM unlock protection issue, it was built to scale to then-emerging mobile commerce and DRM challenges. This is now a mandatory component of the Armv7-A architecture. In the later stages of the Armv7-A architecture, we provided extensions to enable very lean, efficient hypervisors to significantly reduce the overhead of running multiple virtual environments, giving them a very fast, efficient operation and clean separation between these virtual environments. Armv7-A processors introduced since 2010, namely Cortex-A15, Cortex-A7, Cortex-A12, and Cortex-A17, all support these standards. Let's see virtualization in action. By enabling separation of personal and enterprise application spaces, virtualization provides a mechanism for running multiple personas on the same device, each with its own level of secure access to data and applications.
We see this in today's BYOD or bring your own device trend, where there is a need for enterprise to protect its secure data while enabling the user to have access to its potentially insecure web applications on the same device. The virtualization or hypervisor setup will isolate the enterprise and personal areas from each other. Each may be running a different OS or different versions of the same OS, but they all appear and behave as if they own the entire device. Software alone cannot offer robust protection. Broadcasters, operators, and service providers all want to deploy flexible business models and ways to protect high-value premium content and services such as music, video, and games. Enhanced instructions in the Armv8-A enable high-performance DRM solutions capable of supporting video streaming and on-the-fly decompression. Using Arm's TrustZone technology and virtualization capabilities, we put the root of trust into hardware.
System-on-a-chip designers can separate sensitive peripherals through hardware, enabling secure, robust products that save cost and development time. The Armv8-A architecture streamlines all of this, enhancing it by taking the important step of introducing cryptography instructions that make it a lot more efficient to do more secure encrypted operations around a solid virtualization and security infrastructure. The two previous slides show how the new Armv8-A architecture enables system-on-a-chip designers to create hardware that spans future use cases. Even for today's 32-bit applications and software, which is an enormous set of software assets available for Arm platforms today, the benefits of the recently released Armv8-A processors, such as Cortex-A53 and A57, provide significantly better performance than the prior generation ones. When we launched the Cortex-A57 and A53, we said that they would be the best 32-bit processors for their respective classes or market segments.
If you were to take a Cortex-A53 and drop it into the same chip as today's popular Cortex-A7 processor, then run the same software at the same frequency, you would see anywhere from a 20%-60% increase in delivered performance, depending on what you run. If you're running things like browsers or browser-related content, you'd see somewhere between a 40%-50% improvement. Reality is, with improved system design, with the next-generation process technology, and continued software innovation, the actual end devices would show a much higher level of performance, as you can see from the graphs in front of you. The same applies to the Cortex-A57 processor, comparing it to the prior generation Cortex-A15. Developing the software to make best use of the new 64-bit capabilities requires the availability of excellent tools, test platforms, and key open source components.
While developing the architecture and processors based on the Armv8-A, Arm also ensured that the essential tools for development were being made available to software developers and the ecosystem. We've been doing it for the last few years. Arm has created an end-to-end tool solution that helps customers navigate the fastest possible path to market in their Armv8-A design flow. The latest generation of tools developed alongside the Armv8-A architecture includes virtual platforms, code generation tools like compilers, debug solutions, and performance analysis and power analysis. We continue to improve and optimize everything along the way as the architecture matures. We are working with the Linux community through Linaro and its partners. Linaro has been actively developing special interest groups like the Linaro Networking Group and the Linaro Enterprise Group that are rapidly furthering the ecosystem for enterprise networking, wireless infrastructure, and servers.
Arm has also led the way with Base System Architecture for servers, also known as SBSA, which has been a great starting point for partners who can then differentiate around it with their special value for disruptive solutions that provide scaling and TCO relief for today's enterprise world. We have signed over 30 licenses for the Armv8-A-based products. The traditional mobile players such as Qualcomm, Samsung, MediaTek, LG, and Nvidia, along with rapidly rising players like Rockchip, are planning products based on it. You have seen numerous announcements at the recent Mobile World Congress on product lines based off the Arm Cortex-A50 Series. The mobile ecosystem is ramping quickly to utilize these Armv8-A-capable products. We are also seeing Arm licensees that have a great deal of experience designing products for networking, delivering more scalable solutions.
This includes the likes of Broadcom, Huawei, TI, Freescale, Cavium, and OS middleware players like Enea. We've also seen a surge of server announcements, including from stalwarts like AMD. The server software ecosystem with Red Hat, Oracle, and more. As I mentioned previously, the SBSA has been a very useful component for initiatives like the Open Compute Project. Finally, to summarize, we see the applicability of Armv8-A across a broad spectrum of existing and emerging markets. The opportunity spans from low-end devices to very high-end mobile devices, clamshell devices, PCs, and enterprise networking and server. It offers an efficient, common platform for innovation, delivering the right solutions at the right cost at the right time. Armv8-A provides the Arm partnership and its customers a basis for delivering value to billions of end users and for Arm to access a new class of customer.
We are extremely excited about the coming years. Thank you for listening.
Thank you for standing by, and welcome to the Armv8 investor presentation conference call. At this time, all participants are in a listen-only mode. If you require operator assistance at any time, please press star zero on your telephone. I must advise you that this conference is being recorded today, Monday the 24th of March, 2014. I would now like to hand the conference over to your first speaker today, Ian Thornton. Please go ahead, sir.
Thank you, Kelly. Good morning, good afternoon, good evening, everybody. Welcome to this Arm investor relations call. My name is Ian Thornton, and I'm the Head of Investor Relations here at Arm. Today, we are joined by Matt Ramsay, the VP of Equity Research at Canaccord Genuity, and Nandan Nayampally, who's the VP of Marketing for our CPU group and who's been responsible for the development of our Armv8 processor product line. On Friday, we published a pre-recorded presentation given by Nandan on Armv8, and if you haven't had a chance to listen to that, I'd recommend that you do that after this call. It's available on our Investor Relations website at www.arm.com/ir. For today's call, we are going to be focusing on a Q&A between Matt and Nandan.
We're not going to be opening up the phone lines for these questions, but if you have a specific question that you'd like to be addressed, please send an email to myself and Phil at investor.relations@arm.com. With that, Nandan, do you briefly want to give us a bit of an update on who you are and your background?
Thank you, Ian. As previously announced, Nandan Nayampally, I'm the VP of Marketing for the CPU group here at Arm, and that means I'm in charge of the Arm processor roadmap. We also look out into the future for what technologies, what capabilities we need to develop, and naturally, generating all the outbound messaging and data for what the processors bring. In terms of my history, I have been with Arm for almost a decade, and it's been quite an excellent ride, starting with, in fact, the early days of TrustZone and the ARM11, through big.LITTLE technologies, and now here with Armv8. Extremely exciting times. If you go a little bit further back, I actually cut my teeth and started off at AMD almost two decades ago on what became the Athlon processor. Processors, very exciting, and continue to be so.
Okay. Well, thanks, Nandan. Matt, do you want to just give us a little bit of your background and why you are here on this call today, and then maybe go straight to your first question?
Sure. Great. Thanks, Ian. Thanks, Phil, and the rest of the IR team for giving me the opportunity to host the call today. Of course, thanks for Nandan for making the time. My name's Matt Ramsay. I'm a semiconductor and communications technology analyst at Canaccord Genuity. Done a lot of work on Arm and Armv8. My background before coming to the sell side, I was actually a computer architect at AMD and at Sun Microsystems before that. I have a bit of history in this space and have written a bit about Armv8 and its applicability across a slew of end markets, including mobile and some new end markets like enterprise networking and server for Arm. Excited to host the call today.
I'll just jump right into Q&A, and again, if things come in during the call to Ian or Phil's inbox, we'll try to incorporate as many of those questions as we can into the Q&A today to extract as much interesting information to the audience as we can. Again, I'll just jump right in. Nandan, in my discussion with investors and sort of readings of blog and press reports about Armv8, it seems everyone focuses just on 64-bit and ignores many of the other important features of the Armv8 architecture. Obviously, an architecture is a lot more than just how many bits of addressing it supports. I'd like you to maybe walk through, and you did a very good job, I think, in the prepared slides, some of the additional features of the Armv8 architecture.
Maybe you can walk through and quickly recap those here and maybe talk about the particular features that might be applicable to different tiers of end markets across the Arm licensing base.
Okay. Thanks, Matt. What I'd start off with is, you're right. firstly, Armv8 is not just 64-bit, and the architecture is not just the instruction set. As we talked about in the presentation, it's kind of a contract between the hardware and software and what things need to be done together. It kind of defines them. This includes, obviously, the instruction set, the memory models, the software programmer's view, and what you can do with it, what do we do for debug, monitoring, et cetera. If you put that in context and you look at Armv8, as we talked about in the presentation, we started working on Armv8 almost seven years ago, and we were looking at what are the trends that we're developing, right? Which are increase in concurrent programming. At that point, it was still a single core world.
Now we have octa-cores increasing by the minute. We expected the need for security and privacy as the mobile devices became the primary compute device. Obviously, as we looked at things around the industry, not just in the mobile side, but around it, we would need higher levels of compute, not just in terms of the muscle that the processor brings, but what the architecture can do to accelerate. Obviously, the increasing memory needs. If you look at that, the memory needs increasing, that's where actually 64-bit comes in. If you step back and look at what else Armv8 brings. Firstly, there's a wealth of software that's already existing on Arm in 32-bit that has to run really well. Backward compatibility is key. You can maintain backward compatibility while adding new feature set.
This is actually where Armv8 adds quite a lot of value. One, because concurrent programming and large multi-core programming has become important, Armv8 adds some capabilities on more simplified interaction between them and synchronization between these processes, which makes it that much more interesting for things like the newer programming languages like Java 5, C++11, to make them more friendly, make more thread-safe software, and easier from a programmer standpoint. You get to the next set of benefits on improving encryption routines for the constantly connected, secure, and private devices. We introduced the AES and secure hash capability that actually is available not just in the 64-bit world, but in the 32-bit world. You can actually have a very compact Armv8 device that actually utilizes today's software assets with enhancements to improve encryption.
Beyond that, of course, we have the 64-bit architecture, which improves our capability of greater than 32 bits of virtual memory, which we'll certainly see in the higher spec devices. We also increased the capabilities of the Neon multimedia instruction set that actually improves, not just makes the Neon very scalable across both multimedia, but as well as scientific compute. The Armv8 architecture actually scales across very compact, low footprint devices all the way up to very high compute intensive, high memory intensive devices for enterprise networking, server, and HPC.
That's a helpful summary. Just to dig into that a few points further, some of the questions that I get sometimes are, why would a processor or licensee migrate to Armv8 if maybe their memory addressability or the memory constraints of 64-bit aren't something that they really need at that price tier or in that particular device? It sounds like a lot of these features that you discussed there of Armv8 are really applicable across a broad spectrum of tiers of market segments, not just in where high memory is going to really be. Is that a fair assessment? Are there particular examples you could give maybe of companies or of scenarios where Armv8 is really applicable in a lower memory or a lower cost environment?
Yeah, I think you've highlighted it well, right? There is, if you look at v8, different markets will have different issues. The need for 64-bit is one, the need for the other key benefits that we mentioned, I think, are common across a slew of devices. I think you've probably seen the discussion of a $25 phone from Mozilla at the Mobile World Congress, that could actually still utilize the benefits of v8 without having to delve into 64-bit. Again, you say the need for octa-core or larger multi-processing devices. Again, these are in low-cost markets to mid-range markets, not ones that you'd consider very 64-bit intensive, if you will. Again, at the Mobile World Congress, you saw multiple Arm partners announce products based off of the Cortex-A53 for the lower footprint, lower cost markets.
They're all trying to utilize the benefits of the backward compatibility while incrementally improving the experience with security, privacy, and more, right? More efficient parallel programming. That's kind of a high level view. Obviously, where 64-bit comes in is in the larger screen devices, where there is a greater need for memory addressability. Having said that, you can see even devices today that are capable of doing 64-bit still using less than four gigabytes of memory. I think there is a natural tendency to improve a stack that actually starts operating or a common software stack that works across the smartphone, the tablet, and even higher-end devices. You actually simplify the programmer's view, the app stores, things like that, as you move across a set of devices with a common look and feel.
Right. That makes a lot of sense. Obviously, mobile today is Arm's largest end market for royalties. We've written a bit about Armv8's applicability to all price tiers of that mobile market. From what you just discussed, it sounds like that your view is similar to that. I guess the next question that comes to mind then is one of your more prominent licensees announced a 64-bit product that came to market with that in the fall. Since some of the other named partners, Qualcomm, Samsung, MediaTek, others, have announced roadmaps. With Armv8 generating higher royalty potential than the prior architectures, investors often ask the Arm views on not only the potential long-term penetration of v8 into the mobile market, but also, I guess, the speed at which you expect that penetration to happen.
Would love to hear your thoughts on your interactions with your customer base, how those roadmaps are coming, and what you sort of see the progression from where Armv8 is today, with essentially one customer having material shipments in the market towards broad applicability over the next several years in the mobile space.
Okay. Focused on mobile, I think what you've seen, at least over the last few months, is multiple silicon partners talking about not just roadmap, but also timelines for the devices. We do expect that there is a pull too that is coming in, again, coming from a common programmer, a software stack approach that you'd see from larger screen devices first, going to more of a premium handheld type market, and then transitioning further as you go to the same software stack, tracking down into more cost-effective devices for broader penetration. I don't necessarily see us necessarily talking about a percentage of penetration, because certainly there's a strong case on the Armv7 and the 32-bit world continuing for a while. We do see the Armv8 capabilities actually making it into a lot more devices outside of just the 64-bit capability.
No, that's interesting that you bring up the point that the Armv7 and the Armv8 architecture will sort of coexist for a while, and there's still some reasons for some processor vendors or maybe then their end OEM customers to continue on the v7 path. I'd sort of love to hear your thoughts on that, because you've done a great job of articulating the benefits of v8 even outside of just 64-bit. I guess what would be the reasons why a vendor or an OEM would sort of continue along the path that they were on v7, as opposed to adopting v8 other than sort of the migration costs from one to the other?
Given the number of markets we play in, and I would use mobile and consumer as one whole, I guess, a common bucket, if you will. Certainly, the cost of migration is something to consider. Also there's so many markets and sub-markets within it that have a much tighter design cycle and actually value a lot of the maturity of the existing architecture software and time to market. You do see a lot of partners building on that by building products that they fully understand. There may not be a serious value for upsell for them. It's a product that fits the need, it fits the cost profile, it fits the comfort level for what they're servicing. Besides, as I say, I think you might have seen this discussion before, there are over 350 partners we have today that already have Armv7 based product.
There are 20 partners today and probably 30 licensees we've seen Armv8. Naturally, the scope for growth of that market is pretty high, but there's plenty of product that still solves day-to-day problems that you can build with.
That makes sense. I guess switching gears, one of the big attractions from investors' points of view, and I'm sure from yours as well, of the Armv8 architecture and some of the features that it brings is the applicability of Arm's technology to additional markets where Arm maybe had peripheral or almost zero market share in the past, things like server or enterprise networking, et cetera. Some of Arm's more recent presentations, even some data that Ian and the team have put together for investors, have talked about those new markets potentially being the same TAM, maybe say GBP 20 billion by 2018 is the number that's been thrown out on some slide decks, and where Arm has roughly 5% market share today.
I guess maybe you could talk about those end markets a bit. What are the key opportunities but also the key hurdles to the Arm partnership gaining share in those markets versus some pretty entrenched incumbents? Then we can dive into maybe some discussions of what realistic market share is for those markets over the next 5, 10 years in your view.
Okay. I think the natural discussion I think you have is about the enterprise market, as you'd call it. In Arm, when we talk about enterprise, it's actually a broader statement. We do actually look at storage, including the hard disk drive type market as part of enterprise. We look at printing, we look at, obviously, server networking, so on and so forth. If we just showcase the two main ones here, which would be server and networking. I would start with networking first, because you've actually seen a lot of activity on the networking front, especially over the last few months, you might have seen discussions about the 16 core Cortex-A15-based platforms that have come out through Huawei HiSilicon as well as LSI, all demonstrating the capabilities that we talked about a few years back.
More scalable, more power efficient, more cost-effective solutions for the challenges of the networking space. I think you will see we're already moving there with today's Armv7 product, Armv8 actually makes it that much more compelling and broader reaching into that market. If we then look at server, I wouldn't necessarily qualify it as a standalone market because it is evolving. Right? Server as a standalone big iron may be a mechanism used so far, but what we see with the growth of cloud is, networking and servers start getting more interspersed, more closer together, and based on the types of workload, the types of use cases, the solutions also get tuned accordingly. If you can save a microwatt or a milliwatt per transactions and you have trillions of transactions, that's a big difference.
Naturally, the benefits of Arm's business model as well as the solutions that its partners bring actually fit this very well. With that said, we do see, just as the tablet market has eroded or is eating into effectively the PC market, we do see the new approach to servers actually eating into the traditional approach to the enterprise server. To that effect, I think we have been investing consistently into the ecosystem. This is not something new. We've been doing that for years. You can actually see the progress going through as well. In the ecosystem, we started the Linaro group to actually further the open source tooling cause. We've seen the partnership actually build more on top of it with the Linaro Enterprise Group for server, the Linaro Networking Group for targeted work at networking.
You're also seeing cloud service providers and companies like Facebook porting their virtual machines over to Arm. You're looking at a lot of the networking companies working on the Arm ecosystem. We have been working with virtualization vendors, et cetera, to move things like KVM, tested, optimized towards Arm. Overall, there's been a lot of movement towards it. Naturally, the hurdles are initially, it takes time to enter these markets. The software stack needs to mature. The tool chains need to mature. Certainly, you have seen some of the early forays making progress, but maybe at the moment, being judged as not quite there. I think overall, from all we see around the market, people like AMD have talked about their platforms. There are multiple other vendors talking about their platforms going in. We're actually seeing the set of hurdles kind of reducing.
Interesting you talk about the ecosystem, I think similar to big.LITTLE where chips were sort of first brought to market a little under a year ago, folks sort of started to realize that the optimal performance and implementation of these new technologies like big.LITTLE and Armv8 does require a significant amount of ecosystem, software, operating system, et cetera, support. I guess, may I?
I'd love to hear more about, and you touched on a few of them there, but the software, not just the efforts that you and the Arm camp are making of ecosystem development, but some of the key software dependencies for Armv8 to gain share within not just the markets that you mentioned, like enterprise networking and server, but also in the mobile space, whether that's operating system support, 64-bit optimized kernels from Android and Windows and maybe other vendors like Firefox that you brought up earlier. Maybe just kind of talk about the hurdles that we need to get across to see broader 64-bit or Armv8 adoption in both the mobile space and the other markets that you just mentioned, and what Arm's doing to sort of facilitate that software development.
Okay. In terms of the enablement of the ecosystem, we have been as you do, right? We disclose the architecture in late 2011. A lot of the architectural partnerships that we have in this operating system vendors, and key toolchain providers have been aware of what was going on about the architecture even before then. Once we announced the architecture, and then we announced that the products that are based off of it, we have been consistently providing more tuned models for early software development. We have been actually providing the validation kits for our architectural licensees as well as people around the ecosystem. We also invested a lot into the open source enablement.
Around the time we launched the Cortex-A50 Series, which was October 2012, we also put the first version of the Armv8-capable Linux onto the main source tree, as with the Armv8-capable toolchain for GCC into the source tree. It's going on a year and a half to two where the ecosystem has had a chance to play with it and develop based off of it. As now partners announce more platforms available, and there are, as you have seen, platforms already out there in the market that people are designing to. Once the hardware gets out there, the ecosystem catches up pretty significantly, having got a bit of a start with the tools that we've provided. On the mobile side, you would argue that this is an Arm ecosystem.
The majority of the software assets, if not most of them, are based on the Arm ecosystem, and you would see the key components moving to Arm with the tools and the bases that we've provided. In the newer markets, I think, as I said, we have partners who have been respected in the space. You talk about people like AMD, you talk about people like LSI, you talk about people like Broadcom, and they are actually ensuring, along with us, that the software middleware that needs to be in place for the platforms to actually succeed in the market are actually getting there, too.
Thanks. A good example of that would then be like a Server Base System Architecture specification, and the sort of ecosystem work that's going on around that. Is that sort of the types of initiatives that you're speaking of?
Yes. I think this is a very good catch. The Server Base System Architecture is something that builds on what we think is critically required for when I say standardizing, it's more about a statement of actually providing a simple setup where a lot of collaboration can happen with our partnership, and also they can differentiate in their specific points. The Server Base System Architecture is something that we have propagated into the open source. It is something that our partners can build off of and have a common setup. This has an analog in some ways to what happened in the mobile space as well. If you look at a mobile SoC, there are a lot of different components that are integrated in the same platform.
At an abstraction layer, you build to that platform, everything that needs underneath that, the drivers, et cetera, are provided by the different silicon vendors supplying to it. The SBSA does a very similar thing, providing a common abstraction layer to design to while having different platforms that are tuned to solve different problems around it.
We talked a bit about mobile and a bit about some of the newer markets that Armv8 brings into Arm's TAM. It's interesting, from an investor's point of view, Armv8 is sort of one of the tools in the tool belt for Arm to expand the royalty rate, or the royalty percentage rate that it's able to collect on chip sales that utilize Arm's technologies. Other tools in that belt are big.LITTLE, Mali graphics attach rates, physical IP, et cetera.
I wonder if you'd speak a bit about Armv8 and the relationship to those other tools in the tool belt, both in the mobile space and also in some of these newer markets, like server or networking, et cetera. Do you believe that as many of those other tools in the tool belt apply to those markets? Maybe they are less applicable given the workload nature in sort of a server or networking space than it might be in mobile.
I think Armv8, as you said, I think applies across all markets. The natural penetration in some more than others. big.LITTLE as a technology, I think, is a very critical component for mobile, and it's across the range. If you actually notice what was happening, even with the use of eight Cortex-A7s or Cortex-A53s, partners are using the benefits of a slightly imbalanced implementation to make sure that you get the performance that you need and the efficiency that you need. The big.LITTLE technology has taken off in a very big way. Exactly, it's not just a point about premium devices with large scalability, but actually the technology is scaling into mid-range and low-cost devices.
You've probably seen the announcement by Samsung at Mobile World Congress that had a 2-plus-4 system, where two Cortex-A15s and four Cortex-A7s coming together, which again is squarely in the mid-range section, and then you see the Cortex-A7, Cortex-A53 devices going into mid-range to low cost. The same will be applicable for the Armv8 versions of products. In fact, even when we move to more advanced FinFET technologies, big.LITTLE is a tool that builds on top of. It's not replaced by, and in fact, enhances the benefits of it. It is not just mobile now. If you look at energy efficiencies, I think it's critical across. You look at home entertainment, you look at DTV, ENERGY STAR becomes a common requirement. Even for plug into the wall devices, I think energy efficiency is getting critical. big.LITTLE is applicable there.
You look at automotive and infotainment, you look at ADAS, where the Cortex-A class products will also apply. It may not be battery operated, but they're terminally constrained. You have a lot more flexibility that you bring with big.LITTLE there. Interestingly enough, I'm not going to push it into enterprise networking, especially server networking, are markets that do understand the use of heterogeneous systems. big.LITTLE is a heterogeneous system, the concepts or the applicability can be extended beyond, not necessarily in the way it's envisioned for mobile, but the tenets actually apply as well. If you look at Mali and graphics or GPU compute, those are certainly applicable in mobile, again, consumer devices. When you start looking at high-performance compute, maybe server, again, the computational aspects could utilize GPU compute.
Maybe networking infrastructure is probably one of the points where I don't see necessarily the applicability of the GPU compute spectrum, but you never know. Innovation from our partnership always surprises me in a good way.
Indeed. Essentially, hearing you speak about v8 just sort of reminds me of the broad applicability across different end markets, which I guess brings a completely different type of question, which is, Arm has done a great job in the past of not only supporting its architectural licensees, but its individual processor licensees. With maybe a narrower market applicability of v7 and v8, Arm was able to supply processor designs that were applicable across most of the end markets to where v7 was sold. With the broadening of v8 across more end markets, server, networking, et cetera, how might this change the focus of investment from Arm from, say, individual processor designs that might not be applicable across all those end markets, toward things like ecosystem and software development, et cetera?
I'm just wondering how you and your team are thinking about investments on the compute side versus, I guess, processor investments versus ecosystem investments going forward, how that might be different.
I think it's a fair question because it is also a pretty detailed question. I'll try to address it in the key points. In terms of ecosystem investment, I think it doesn't matter at that point whether it's a processor that's designed by Arm or by an architecture licensee. Right? The software assets and the tool chain, et cetera, that get built have to run, whether it's an Arm-designed processor or not. The ecosystem investment will continue. One of the benefits, again, of the business model that we've had is that it is amortized across the partnership to actually give value to everybody. Arm has to in fact steer and push that ecosystem investment. We continue to do that. In terms of the investment for design, I think, again, that doesn't change.
In a lot of ways, Arm being ahead in the architecture, in fact, driving it, a lot of the investment has already gone into what we've developed. When we talk about networking server, et cetera, we've been investing for the last few years into cache-coherent networks, these products that are already out there. The level of investment that we've put into this has already been planned and developed with. We continue to invest at the levels needed to keep these markets growing. If you look at what we're doing for mobile, it's consistently growing. For enterprise and server and the infrastructure markets, we've already invested. You've seen us talk about 16-core platforms that are already in the market that are built off of Arm, not just processors, but system IP. We talked about how that would go to 32-core solutions. Again, we announced that last year.
I think we are continuing to invest just at the same level that we see across all these markets.
I guess the question really comes across in the prior question was really on Arm's sort of margin structure and investments in the ecosystem. Hopefully, there are broadening end markets to extract revenue from that would amortize these investments, but you don't see a material increase in the amount that you're going to need to invest to really chase after these new opportunities. In the past, say you've had an A15 processor that's designed by Arm and focused and licensed it. I wonder, in the future, if there might be versions of processors that were directed at certain end markets that Arm might forward and I guess wonder about the increased investments to support something like that. Or do you think that the investments you made in the architecture can make designs that Arm makes applicable to most of the end markets that V8 might touch?
Matt here, it's Ian. I'll step in if we're going to start getting into margin structures, because that's more speaking to the overall structure of the business. I think the key thing is that we still expect to be able to drive licensing, drive royalties faster than our costs, so still leading to increasing margin. I take the point around do we need to go and build specific processors for specific end markets. Our approach has been always, and maintains, to still develop very general-purpose processors. To a certain extent, that's one of the benefits of the architecture license, is that if there is a niche market that is completely unique and our general-purpose processors aren't ideal for that, then that's exactly where an architecture license could come in, because someone could then go and build something for that specific market.
Therefore, there's no impact on our overall profitability because that's just another license. It's already technology that's been developed. There's no extra cost for us to go and address that market with the architecture license.
Thanks, Ian, for that. Sorry, didn't mean to jump down the typical financial analyst rabbit hole there.
No.
I guess since this is an investor analyst call, I guess we had to get the numbers at some point. Maybe Nandan or Ian, you guys could remind us again the expected royalty rate expansion for Armv8 versus v7 versus a comparably configured v7 processor. Is there a way that we should think about looking at the base of that royalty rate going forward? Since we've been discussing here the mix of processor versus architectural licensee shipments, do you see that mix being materially different for v8 going forward than it was for v7, and how do the royalty percentages compare between those two?
I think firstly, I may not get into the specifics of the royalties for two reasons. One, it is a simple question but a complex answer. The licensee and the royalty are determined by quite a few factors, among them the complexity of the technology and the value that is being realized, right? Also, depending on the market and depending on how they turn out, there are, I guess, complexities that I can't talk about. The simple answer, I would say, is as the products get more complex and more advanced, the value to the customer and the end market increases, and this is kind of reflected in the pricing. I think that's the best I can say about it. Ian, if you want to add anything.
I mean, basically, the best way of thinking about it is the Cortex-A53, Cortex-A57, the technologies that are based on the Armv8 architecture are by far the most complex and sophisticated processors that we've built to date. They've been Arm's biggest investment that we've ever made to date. The way that we monetize that is through the licensing and the royalties. You would expect that if cost is going up, if value to our customers is going up because we're saving them more money, you'd expect us to expect them to pay some more money for that.
Yes, that seems reasonable. I guess on the licensing side then, since we kind of segued there. Nandan, in your prepared slides, you discussed that v7 had, say, 130 plus licenses over 80 licensees, and has quite a few iterations of processor designs there. Armv8 is much newer. Really only two chips have been designed and licensed, but the architecture's been licensed to a broader base. Seems like from the stats I've seen, 30 licenses so far across, say, 20 companies. I just wonder your perspective on sort of what inning we might be in as far as licensing of Armv8. With the new end markets that it brings to bear, it seems like the licensing potential of the new architecture could potentially be broader.
Just love to hear your thoughts on the size of the licensing, say, TAM, that you're going after with Armv8 versus v7, and sort of where we are in that progression.
Okay. I think you brought up a fair point, right? There's a potentially new TAM. There's a potential TAM for what we already have. I think the best way to describe it is it's early days, right? We can see the applicability to a lot of these markets, and certainly a lot of partners have licensed the architecture and the products themselves to make plans for addressing these markets. Do we see this as a replacement for v7? I don't think so. There's a lot of markets that will continue to be v7 because you have to realize v7 from an applications processes standpoint, certainly it'll be applicable, but there are also microcontroller side and real-time processing side that will continue there for a while.
I guess the total figure is probably tough to come by. Coming up with a penetration level or a licensing TAM, again, I wouldn't speculate. I think there will be a broad applicability of Armv8 to the markets that are served by Armv7, and they continue to coexist.
Thanks for that. I guess it looks like the time sort of flown by here. Sounds like it's pretty close to time to close the call. I really do appreciate, Nandan, you taking the time and giving me the opportunity to host the call. To Ian and Phil, thanks again. Those who participated on the call on the phone, I hope you found this useful and informative. You folks know where to find me if you want to follow up. Just pass the call back to Ian. Thanks very much.
Okay. Thank you, Matt. Thank you, Nandan. Thank you for everybody for listening in. Just to let you know that there will be a recording of this call on the website shortly, in case you want to listen again. We'd be very keen on your feedback so we can do these calls better in the future. The next call is being planned for the end of Q2, when Colin Alexander will be joining us to talk about the opportunity for Arm in enterprise networking. I hope that you've enjoyed this call and I hope that you'll dial into the next one as well. Thank you all very much.
Thank you.
That does conclude our conference for today. Thank you for participating. You may now disconnect.