Status Update

Mar 24, 2014

Slides

I'm London Lamboli, the vice president of product marketing in Arm 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 V Eight A Processor Architecture. The lagging A in Arm V8A 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 1st arm CPUs that are based on the Arm V8A architecture. As you may recall, in October, we also announced and RB8R 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 Arm V Eight a specification in particular. I will then have a look at some of the technical features that we've introduced in the RB8A, and the new use cases that that are enabled for new users. And finally, I will look at how ARM8A Ecosystem is expanding today and where we as our partnership see the opportunity. Before we jump into some of our technical aspects of RB8A, 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. ArmV8A is that platform, and its development is one of the largest projects ever undertaken at Arm. Now 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 five thousand 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 Arm V8A architecture and the software written for one of these processors will run on the other. Arm not only relicenses 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 applied microsex gene processors are in house designs that conform to the Arm V8A 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 1 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 arm chip, the Arm 1, was built by Acorn in 1985, a chip that ran at 8 Megahertz, fitted with 4 megabytes of RAM and powered the popular BBC microcomputer. 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 on B4, which introduced thumb instruction set and was a part of the conic ARM 7 TDMI processor that fueled the early digital mobile phones. In the 15 years since 1998, Arm has released 4 new architectures. Each of these introduced with an 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 Arm 1 chip contained 25,000 transistors and was designed by a team of 5 engineers. Today, a leading edge system on a chip might contain a billion transistors and ARM Processes within those chips are a result of 100 of manures 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 arms Architecture Group started to define the RB8A Architecture in 2007. Nearly 7 years ago. Once the specification was finalized, Arm CPU engineers commenced the design of the Cortex A53 and 8507 processors. These processors were licensed to our lead customers around 2 years ago, And the first CORTEX A53 chips from our partners will be available, soon this year. There is no doubt that the RMB8A architecture licensing got off to a very strong start, but there is plenty more to come. So far, we have developed 2 Cortex A products for the Arm V8A architecture and signed 30 licenses with 20 companies In comparison, the RB7a architecture, we have released 7 processor or CPU designs and signed over 130 licenses with over 80 companies. As the NVAA technology matures, It will be marketed to 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 in 2003 and in 2014, we released the latest version of the RMV7A Processor, the Cortex A 17. We expect there to be Let's cast our minds back to 2007 when work commenced on the RB8A. The smartphone revolution had just begun, but the early devices cost over $600 and were used exclusively by the LP. In contrast, billions of people in low income economies were using voice only phones based on the Arm V4 architecture. One of the key goals of Arm V Eight A was that it should be making more advanced computing affordable to all. We wanted to see armed V8A processors in $60 phones, not just $600 phones. That way, developers would be able to target 1,000,000,000 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, and 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 1 or 2 directions. They either created a brand new architecture, excluding any efficient legacy mode, or they added 64 bit to an existing 32 bit which drove up decoding complexity and other inefficiencies. The mandate for the armed V8A 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, RMV8A has 2 processes states, ARS32 and ARS64. ARGE 32 supports all thirty two bit legacy ARM software. It streamlines the existing 30 two bit ARM V7 architecture and adds new capability and instructions for cryptography and to improve efficiencies in concurrent programming. The AR64 is a brand new instruction set. The 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 process data manipulation on devices and cloud based platforms. It also introduces an advanced vector mathematics capability for compute intensive activities. The coexistence of AR-thirty two and AR-sixty four processor states allows an ARM-eight 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 parts between the two states. The incremental size increase, therefore, between a 32 bit process and 64 processor is only the order So how did we design RMB8 for efficiency? As you might expect from a modern architecture, RMV8 is designed to continue to support efficient virtualization, trust zone security and the other key benefits of the RMV7A ARC year. To extend this, we also introduced new cryptography instructions that speed up encryption software routines for AES and secure hash by nearly ten times. This makes it a lot more efficient to bolster consumer privacy and enterprise security on the hardware itself. Additionally, In arms architecture, where the software community calls the memory ordering model is designed for low power operation. In Arm V Eight A, across both 32 bit 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 multi processing operations become more efficient. This is a major benefit for today's consumer devices that use quad and octa core processing solutions. In the ARTS 64 state, We took the opportunity Arm's neon technology accelerates multimedia and signal processing algorithms such as video and code, decode, 2 d and 3 d graphics, gaming audio. Speech processing and some levels of image processing. RMA doubled 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. Now putting it all together, we get a basis for platforms that can scale crossed everything from low cost phones to secure high end mobile devices that deliver desktop class performance while fitting in your pocket. Arm V Eight processes today delivered more performance on existing 32 bit software. But with the 64 bit state, we allow the processes to address more memory. We will see consumer devices with 4 to 16 gigabytes of in the near future and enterprises devices with terabytes. We focused on running this more complex software stack and more complex of 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. 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 30 DIBDARM Processors, are a increasingly seeing these console quality games and arms 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 RB8A, we extend this benefit to make that RMV8A 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 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 for solace over a decade ago and has been progressively building technology into the arm architecture over this period. In the late stages of the ARM V6 architecture, with the ARM1176 Processor in the year 2003, We introduced trust zone as a mechanism to put the root of trust in hardware. While it started off as a SIM unlocked protection issue, it was built to scale to then emerging mobile commerce and DRM challenges. This is now a mandatory component of the Horn V7A architecture. Then in the later stages of the RMV7A 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 ARM B7A Processors introduced since 2010, namely Cortex A15, Cortex A7, Cortic C12 and Cortex C17 all support these standards. Now, 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 DBIOD 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 set up 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. Enhance instructions in the RB8A enable high performance DRM solutions capable of supporting video streaming and on the play decompression. Using Arm's trust zone technology and virtualization capabilities, we put the root of trust into hardware Now, system ownership designers can separate sensitive peripherals through hardware, enabling secure, robust products that save costs and development time. The arm VAA architecture streamlines all of this, enhancing it by taking the important step of introducing cryptography instructions that make it a lot more The two previous slides show how the new RB8A architecture enables system ownership designers to create hardware that spans future use cases. But even for today's 32 bit applications in software, which is an enormous set of software assets available for ARM platforms today, the benefits of the recently released RB8A processors such as Cortex A53 and A57 provides significantly better performance than the prior generation ones. When we launched the Cortex A57 and A53, we said that they would be the best 30 to bid processors for their respective classes or market segments. As an indication, if you were to take a Cortex A53 and drop it into the same chip as today's popular Cortex A7 processor, and then run the same software at the same frequency, you would see anywhere from a 20% to a 60% increase in deliberate performance depending on what you run. If you're running things like browsers or browser related content, you'd see somewhere between a 40 to 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 A 57 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 Arm V8A, Arm also ensured that the essential tools for development were being made available to software developers and Arm has created an end to end tool solution that helps customers navigate the fastest possible path to market in their Arm V8A design flow. The latest generation of tools developed alongside the ArmVADA architecture, includes virtual platforms, cogeneration 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 Lynaro and its partners. Linaro has been actively developing special interest groups like the Lynaro Networking Group and the Lynaro 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 Arm V8A based products. The traditional mobile players such as Qualcomm's Samsung Mediatech, 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 A 50 series. The mobile ecosystem is ramping quickly, to utilize these armed V8A capable products. We're also seeing armed 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 Hennia. We've also seen a surge of server announcements including from stalwarts like AMD and the surf 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 RB8A 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. Arm V Eight 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 ArmV 8 Investor Presentation Conference Call. At this time, all I must advise you that this conference is being recorded today, Monday, 24th March 2014. I would now like to hand the conference over to your 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 Nann Pally, who's the VP of Marketing for our CPU group and who's been responsible for the development of our RMV Aid process of product line. On Friday, we published a prerecorded presentation given by Landan on Arm V Eight. And if you haven't had a chance to listen to that. I'd recommend you that you do that after this call. It's available on our investor relations web site at www.arm.com/ir. And so for today's call, we are going to be focusing on a Q And A between Matt and Nandan. We're not going to be opening up the phone lines to 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 at arm.com. And with that, Nanda, do you just please want to give us a a bit of an update on who you are in your background? Thank you, Ian. So as previously announced, the big piece of marketing for the CPU group here at Arm. And that means I'm in charge of the ARM Processor road map. 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've been with Arm for almost a decade. And it's been quite an excellent ride, starting with, in fact, the early days trucks zone in the arm 11 through Big Little Technologies and now here with ArmV-eight, extremely exciting times. If you go a little bit further back, I actually cut my teeth in started off at AMD almost 2 decades ago on the what became the Athlon Processors. So processors very exciting and continue to be so. Okay. Well, thanks, Alan. And Matt, do you want to just give us a little bit of your 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. And of course, thanks for 99 for making the time. My name is Matt Ramsey on the Semiconductor And Communications Technology Analyst, the Canaccord Genuity. Done a lot of work on arm and arm V8. My background, before coming to the sell side, I was actually a computer architect at AMD and at Sun Microsystems before that, so a bit of history 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 arms. So excited to host the call today. So I'll just jump right into Q And 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 and A today to extract as much interesting information to the audience as we can. So again, I'll just jump right in. And then in my discussion, with investors and sort of readings of blog and press reports about RMBS. It seems everyone focuses just on 60 orbit and ignores many of the other important features of the RMB 8 architecture. And obviously, in architecture is a lot than just how many bits of addressing it supports. So I'd like to maybe walk through and you did a very good job, I think, in the prepared slides, some of the features of the RMBS architecture. But maybe you can walk through and quickly recap those here and maybe talk about the particular features might be applicable to different tiers of end markets across the arm licensing base. Okay. So thanks. Matt. And what I'd start off with is, you're right. The architecture is not just firstly, ARM aid is not just 64 bit. And the architecture is not just the instruction set. So 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 programmers view and what you can do with it, what do we do for debug, monitoring, etcetera. If you put that in context and you look at RMV-eight, as we talked about in the presentation, we started working on RMV-eight almost 7 years ago. And we were looking at what are the trends that we're developing, right? So which are increase in concurrent programming at that point still a single core world. Now we have Octa Chorus, if increasing by the minute. We expected the need secured in 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 the muscle that the processor brings, but what the architecture can do to accelerate. And obviously, the increasing memory needs Now if you look at that, the memory needs increasing, that's where actually it's like super fluid comes in. But if you step back and look at what else RBA brings, Firstly, there's a wealth of software that's already existing on ARM and 32 bit that has to run really well. So backward compatibility is key And you can maintain backward compatibility while adding new feature set. And this is actually where Arm BA adds quite a lot of value. 1, because concurrent programming and large multicore programming has become important armb8 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 plus plus 11, to make them more friendly, make more thread safe software and easier from a programmer standpoint. Then you get to the next set of benefits on improving encryption routines for the constantly connected, secure, and private devices. So 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. So you can actually have a very compact on VA device that actually utilizes today's software assets with enhancements to improve encryption. And then 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. But we also increased the capabilities of the neon multimedia, Instruction 7 that actually improves not just makes the neon very scalable across both multimedia, but as well as scientific compute. So the ARMV8 architecture actually scales across a 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 licensee migrate to arm VA if maybe the memory addressability or the memory constraints of 64 aren't something that they really need at that price tier or in that particular device. And it sounds like a lot of these features that you discussed there of RMB are really applicable across a whole, a broad spectrum of tiers of market segments, not just in where high memory is going to really Is that a fair assessment? And I mean, are there particular examples you could give maybe of companies or of scenarios where armed is really applicable in a lower memory or a lower cost environment? Yes, I think you highlighted it well, right? So there is, if you look at different markets will have different issues. The need for 64, but is 1. And 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 about $25 phone from Firefox at the Mobile World Congress And that could actually still utilize the benefits of V Eight without having to delve into 64 bit. And again, you say the need for optical 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. But again, at the Mobile World Congress, you saw multiple ARM partners announced products based off of the Cortex A53 for the lower footprint, lower cost market, And they're all trying to utilize the benefits of the backward compatibility while incrementally improving the experience with security, privacy, and more, right, and more efficient, problem programming. So kind of a high level view. Obviously, where 64 of it comes in is in the largest screen devices, where there is a greater need for memory addressability. But having said that, you can see even devices today that are capable of doing 64, but still using less than 4 gigabytes of memory. I think there is a natural tendency to improve the stack that actually starts operating or a common software stack that works across the smartphone, the tablet on even higher end devices. So you actually by the programmers do, the app stores, things like that as you move across a set of devices with a common look and feel. Right, right. That makes a lot of sense. Obviously, mobile today is largest, is arm's largest, end market for royalties. So we've written a bit about ARM VA's applicability to all price tiers of that mobile market. And 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, what licensees announced a 64 day product that came to market with that in the fall. And since some of the other named partners Qualcomm some media techs others have announced road maps. So, with arm VA generating higher royalty potential, than the prior architectures, investors often ask for views on to not only the potential long term penetration of V Eight into the mobile market, but also I guess the speed at which you expect that to happen. So, would love to hear your thoughts on your interactions with your customer base, how those roadmaps are coming and what you sort of see from where armediated today with essentially one customer having material shipments in the market towards, broad applicability over the the next several years in the mobile space. Okay. So 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 through that is coming in, again, coming from a common programmers who come in 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. So I don't necessarily see us necessarily talking about a percentage of penetration because certainly there's a strong case on the RMV7 and the 32 bit world continuing for a while. But we do see the the ARMV8 capabilities actually making it into a lot more devices outside of just the 64 bit capability. That's interesting, that you bring up the point that the RMB7 and the RMB8 architecture will sort of coexist for a while and there's still some reasons for some processor vendors maybe then their end OEM customers to continue on the 7 path. I'd sort of love to hear your thoughts on that because you've done a great job articulating the benefits of V Eight even outside of just 64 bit. But I mean, guess what would be the reasons why a vendor or an OE would sort of continue along the path that they were on on C7 as opposed to adopting D8 other than sort of the migration costs from one to the other? So given the number of markets we play in, and, I would use mobile and consumer as a one whole I guess, a common bucket, if you will. Certainly, the cost of migration is is something to consider. But also, there's so many markets and submarkets 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. And 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. Right? So 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 RB7 based product. There are 20 to 20 partners today and probably 30 licensees we've seen RMBS. Naturally, the scope for growth of that market is pretty high, but there's plenty of product that still solves a 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 VA architecture and some of the features that it brings is the, I guess, the applicability of arms technology to additional markets where arms maybe had peripheral or almost 0 market share in the past, things like server or enterprise networking, etcetera. And some of Arm's more recent presentations, even some data that Ian and the team together, for investors, have talked about those new markets potentially being the same TAM, maybe say 20 dollars by 2018 is the number that's been thrown out in some slide decks and where ARM has roughly 5% market share today. I guess maybe you could talk about those in 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 trenched incumbents. And then we can dive into maybe some discussions of what realistic market share is for those markets over the next five ten years in your view. Okay. So I think the natural discussion I think you have is about the enterprise market, as you 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. And if we just showcase the 2 main ones here, which would be a 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 been up through Huawei, high silicon 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 RB7 product and V8 actually makes it that much more compelling and broader reaching into that market. If we then look at server, I think server is a I wouldn't necessarily qualify as it as a standalone market because it is evolving. Right? Sherpa, as a standalone big iron, maybe 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 Microwater a Milliwatt per transactions and you have trillions of transactions, that's the big difference. So 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 this, the traditional approach, to the enterprise server. And 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. And you can actually see the progress going through as well. In the ecosystem, we started the Lenaro group, to actually further the open source tooling cause. We've we've seen the partnership actually build more on top of it with the Lenovo Enterprise Group for server, the Lenovo networking group for targeted work at networking. And 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, etcetera, to move things like KVM tested, optimize towards ARM. So overall, there's been a lot of movement towards it. Naturally, the hurloughs are initially, it takes time to enter these markets. The software stack needs to mature, the toolchains need to mature. And certainly, you have seen some of the early forays making progress, but maybe at the moment being judged is not quite there. But I think overall from 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 that the set of hurdles kind of reducing. Interesting. You talk about the the ecosystem. And I think, similar to big little where chips were sort of first brought to market a little under a year ago and folks sort of started to realize that the optimal performance and implementation of these new technologies like Big Little And V Eight does require significant amount ecosystem, software operating system, etcetera, support. I guess, 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 out of ecosystem development, but some of the e software dependencies for RMBS to gain share within not just the markets that you mentioned like enterprise networking and server also in the mobile space, whether that's operating system support, 64 bit optimized kernels from Android and Windows and maybe other like Firefox that you brought up earlier. So maybe just kind of talk about the hurdles that we need to get across to see broader 64 bit or our VA adoption in both the mobile space and the other markets that you just mentioned and what arms doing to sort of facilitate that software Okay. In terms of the, enablement of the ecosystem, We have been as you do, right? We disclosed the architecture in late 2011, the a lot of the architectural partnerships that we have in this operating system vendors and key tools and 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 architecture licenses as well as people around the ecosystem. We also invested a lot into the open source enablement in around the time we launched the CORTEX A 50 series, which was October 2012, We also put the first version Sourcetree as with the ARMV8 capable tool chain for GCC into the Sourcetree. So it's going on a year and a half to 2 where the ecosystem has had a chance to play with it and develop based off of it. And 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 too, once the hardware gets out there, the ecosystem catches up pretty significantly having got a bit of start with the tools that we provided So on the mobile side, you would argue that this is an arm ecosystem. The majority of the software assets, it's not most of them are based on the army ecosystem. And you would see the key components moving to arm with the tools and the basis 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 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. And so a good example of that would be like a server based system architecture specification for and the sort of ecosystem or that's going on around that? Is that sort of the types of initiatives that you're speaking of? Yes. I think, this is, I mean, a very good catch. The server based 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. So the server based system architecture is 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. And this has an analog in some ways to what happened in the mobile space as well. If you look at a mobile SSC, there are a lot of different components that are integrated in the same platform. At an abstraction layer, you build to that platform, but everything that needs underneath that, the drivers, etcetera, are provided by the different the vendors supplying to it. The SBSA does a very similar thing, providing a a common abstraction layer to design to, while having different platforms that are tuned to solve different problems around it. So, I mean, we talked a bit about mobile and a bit about some of the newer markets that RMBS brings into to arm's TAM. It's interesting the from an investor's point of view, arm VA is sort of one of the tools in the tool belt for Arm to expand the royalty rate that is there or the royalty percentage that it's able to collect on chip sales that utilize arms technologies. Other tools in that belt are big little molly graphics attach rates, physical IP, etcetera. I wonder if you'd speak a bit about, RMBS and the relationship to those other tools in the tool belt. Both in the mobile space and then also in some of these newer markets like server networking, etcetera, do you believe that as many of those other tools in the tool belt apply to those markets or maybe they are less applicable given load nature in sort of a server or networking space than it might be in mobile? Okay. So, I think ArmV8, as you said, I think we 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 8 cortex A7s or a cortex A53s, partners are using the benefits of a slightly invalid implementation to make sure that you get the performance that you need, and the efficiency that you need. So the big little technology is taken off in a very big way. And exactly, it's not just a point about, premium devices with large scalability, but actually the technology scaling into mid range and low cost devices, you've probably seen the announcement by Samsung at Mobile World Congress that had a 2+4 system where 2 cortex A15s and 4 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 midrange to low cost. Now the same will be applicable for the RMV8 versions of products. And 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. You have even for plug into the wall devices, I think energy efficiency is getting critical. So 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 currently constrained. You have a lot more flexibility that you bring with big little there. Interestingly enough, and I'm not going to push it into enterprise networking, but especially server networking, our market that do understand the use of heterogeneous systems. And Big Little is a heterogeneous system. So the concepts or the applicability can be extended beyond not necessarily in the way it's envisioned for mobile, but the tenants actually apply as well. If you look at Malian graphics or GPU compute, Those are certainly applicable in mobile. Again, consumer devices But when you start looking at high performance compute, maybe share where, 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. It's interesting hearing you speak about, on VA, 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, and with maybe a narrower market applicability of RB7 and B8, it was able arm was able to supply that were applicable across most of the end markets to where V7 was sold with the broadening of V8 across more end market, server, networking, etcetera. How might this change the focus of investment from armed from individual processor designs that might not be applicable across all those end markets toward things like ecosystem and software developments, etcetera. I'm just wondering how you and your team are thinking about investments on the compute side versus, I guess, processor versus ecosystem investments going forward and how that might be different? I think it's a fair question because it is also a pretty detailed question. So 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 a an architecture licensee, right? So the software assets and the tool chain, etcetera, that get filled have to run, whether it's an on design processor or not. So the ecosystem investment will continue. And one of the benefits again of the business model that we've had is that it is amortized across the set of partner across the partnership to actually give value to everybody. So Arm has to in fact steer and push that ecosystem investment and we continue to do that. In terms of the investment for design, I think again, that doesn't change. And if you, in a lot of ways, the, you know, arms being ahead in the architecture, in fact, driving it, a lot of the investment has already gone in to what we've developed. So when we talk about networking server, etcetera, we've been investing for the last few years into cash cohost networks, these products that are already out there. So the level of investment that we kind of put into this is already been planned and developed with. We continue to maintain our invested the levels needed to keep these markets growing. So if you look at what we're doing, for mobile. It's consistently growing for enterprise and server and the infrastructure market 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. So 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 crossed in, the prior question was really, on armed sort of margin structure and investments in the ecosystem don't think with the hopefully there are broadening end markets to extract revenue from that would advertise 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. I mean, in the So say you've had an A15 processor that's designed by arm and folks can license it. I wonder in the future if there might versions of processors that were directed at certain end markets that Arm might put forward. And I guess wonder about the increase in 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 sort of most of the end markets that the might touch. Matthew, it's in. I'll step in if we're going to start getting into sort of margin structures because that's sort of 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 that cost. So still leading to, increasing, increasing margin. I take the point around, do we need to go and build specific processes for specific, end markets. I mean, our approach has been always a mid term and maintains to still develop very general purpose processes. And to certain extent, that's one of the benefits of the architectural licenses. If there is a, a niche market that is completely unique. And now our general purpose processes aren't ideal for that, then that's exactly where an architectural come in because someone could then go and do something for that specific market. And so therefore, that doesn't there's no impact on our overall sort of 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. And sort of didn't mean to jump down the typical financial analyst rabbit hole there. 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 sort of remind us again that the expected royalty rate expansion for RMV8 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? And since we've sort of been discussing here the mix of processor versus architectural licensing shipments, do you see that mix being materially different for VA going forward than it was for Visa and how do the royalty percentages compare between those 2? I think firstly, I may not get into the specifics of the royalties, for 2 reasons. 1, it is a simple question but a complex answer. The licensee and the royalty are determined by quite a few factors, amongst them, the complexity, the technology and the value that 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 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. And Ian, if you want to add to that. I mean, yeah, I mean, basically the best way of thinking about it is that cortex A53, cortex A57, the technologies that are based on the RBA architecture are by far the most complex and sophisticated processes that we've built to date. They've been Almed's biggest investment that we've ever made to date. And the way that we monetize that is through the licensing and the royalties. And so you would expect that, if value is going if cost is going up, it's value to our customers is going up because we're saving them more money, you'd expect them after or you'd expect us to expect them to pay some more money for that. If that seems reasonable. And I guess on the licensing side, then since we kind of segway there, And on 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. RMBS much newer, really only 2 chips have been designed and licensed, but the architecture has been licensed to a broader base. Seems like the on the SAS 1630 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 ArmV-eight. With the new end markets that it brings to bear, it seems like that the licensing potential of the new architecture could potentially be broader. And just love to hear your thoughts on the size of the and seeing, say, TAM that you're going after with B8 versus C7 and sort of where we are in that progression? Okay. So I think you've brought up a fair point, right. It's, there's a potentially new time, it's a there's a potential TAM for what we already have. But I think the best way to describe it is it's early days. Right? So we can see the applicability to a lot of these markets. And certainly, a lot of partners have licensed the architecture and and the product 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 market 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 the microcontroller side and real time processing side that will continue there for a while. But I guess the total figure is probably tough to come by and coming up with a penetration level or a licensing Tom, again, I wouldn't speculate, but I think there will be a broad applicability of ARM V8A to the markets that are served by ARM V7A. And they continue to coexist. Thanks for that. And I guess it looks like the time sort of flown by here and sounds like it's pretty close to time to close the call. I really do appreciate Nandani taking the time and giving me the opportunity to the call and to Ian and Phil. Thanks again. Those are participating on the call on the phone. I hope you found this useful and informative and 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, and thank you, Nandan, and 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'll be very, very keen on your feedback so we can do these calls better in the future. And in fact, 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. So, I hope that your enjoyed this call and hope that you'll dial into the next one as well. Thank you all very much. That does conclude our conference for today. Thank you participating. You may now disconnect.