Name: (AP1) Software Guided Intelligence for Physical AI platform design
Uploaded: 2026-04-29T14:56:08.362Z
Duration: 30 min 4 s
Description: (AP1) Software Guided Intelligence for Physical AI platform design

Transcript for "(AP1) Software Guided Intelligence for Physical AI platform design": Hi, everyone. I'm your host, Alia Shokov of Power Electronics News. Thank you for tuning in to this presentation. We're about to hear from Sam Grove, head of software and tools at MIT. He brings over twenty years of experience across the RISC V and ARM ecosystems with previous leadership roles at Psi V and ARM spanning compiler tool chains, development tools, and software platforms for high performance embedded in AI applications. And now on to the presentation, software guided intelligence for physical AI platform design. Good morning, everyone, and thank you for joining me today. I'm Sam Grove, head of software and tools at MIPS, now a GlobalFoundries company. It's a pleasure to talk with you about something that is transforming not only how we build chips, but how we build entire platforms, software guided intelligence for accelerating physical AI platform design. And let me start by saying this is not just an incremental shift. It's a fundamental change in how customers engage with us, how we co design systems, and how we deliver optimized, scalable, AI enabled platforms for the next generation of autonomous and intelligent edge devices. Almost a year ago, GlobalFoundries completed the acquisition of MIPS, bringing together a unique combination of processor IP, software and tools expertise, SoC design capabilities, packaging technology, and world class manufacturing. For customers, this means something unprecedented. One company can now engage across the full stack, from software to architecture to IP to silicon to advanced packaging. GF's differentiated process technologies and global manufacturing footprint make it possible to produce highly efficient RISC V computing solutions targeting transportation, robotics, and embedded AI platforms at scale. And with over forty years of experience building scalable processor technology, compiler tool chain, system software, and workload first platforms for the most demanding compute intensive applications, we are ready for what comes next, physical AI being built on MIPS plus GF. In the old world, customers would call us and say, I got your chip. I need more info on the register programming model. That was the relationship, a hardware first, software later engagement. Today, the conversation starts completely differently. Here's the platform I wanna build. How do we design the most efficient system for it? This is a dramatic shift. It means customers are no longer asking for components. They're asking for platform architecture, workload specific optimization, and codevelopment that starts far earlier than it ever has before. And that's exactly where software guided intelligence becomes essential. AI workloads are pushing closer and closer to the edge, into cars, robots, smart infrastructure, industrial automation, and consumer devices. One of the most obvious optimizations is local data, local compute. To support this, system design has to be software first, has to be built on open standards, and has to be composable in nature. This means architectures must be software defined, where compute blocks can be tuned for specific applications, and open ecosystems like RISC V not only make this possible, they accelerate it. MIPS has maintained its own ISA for over forty years, and the industry has made it very clear. Scale can only happen when we come together and collaborate. Pseudo standards based on supplier customer relationships will not be suitable for the long term. Scalable distributed compute is now the default expectation, and that means software must lead hardware, not follow it. At MIPS, we built the Atlas software and tool stack around this idea. The heart of this concept is simulation technology. Atlas Explorer brings together virtual platforms and microarchitectural models, which provide fast and early insights into system behavior long before RTL, FPGA prototypes, or silicon exists. And with this technology, we provide software guided intelligence throughout the entire product development life cycle. You can start by evaluating workloads using virtual platforms and microarchitectural models of our processor cores. Based on these results, tune and refine the overall system design. This iteration is the heart of software hardware co design. By the time you have silicon, your software stack is optimized for the application and is ready to be deployed, freeing up your design teams to start on next generation products. This is where shift left becomes real. We are no longer limited to functionally correct software porting and bring up activities. You start optimizing before the hardware even exists. Atlas Explorer inside Visual Studio Code lets teams not only simulate workloads, but optimize performance and validate design decisions before RTL, during emulation, and after tape out. With Atlas Explorer, you can see microarchitectural details like memory activities, cache locality, branching trends, ALU, VPU, and NPU utilization, IPC, and much, much more. Let me say this directly. As a software engineer, waiting for RTL or silicon to start software development is no longer viable. This is a problem that we have been hearing about in the embedded systems industry for more than ten years. I mean, I had the same problem twenty years ago as a design engineer, and I think it's safe to say that the same problem existed long before that too. But let's talk about what's driving this in modern times because the system architecture has changed. Modern SoCs are getting larger and incorporating more functionality that used to be handled by discrete components with stand alone firmware, each with their own compute capabilities. Now these are connected with crossbars and knocks integrated together with timing sensitive interfaces. This consolidation has driven cost down, power down, area down with process technology and yield improvements. BOM costs are down too, and there's less to integrate outside the chip. Sounds too good to be true. Right? Well, it is. This increases the software complexity by orders of magnitude. This is exactly why delaying software bring up an optimization creates massive risks even for the most state of the art design teams. Missed opportunities for software to shape architecture decisions. Living with software workarounds that degrade performance for the life cycle of the product. Worst case, missed market windows due to additional silicon spends and costly rework that blow program budgets. We've all seen that movie and lived it, and no one wants to see it again. No sad robots that leave customers with deflated expectations because they're always needing to be charged or always tethered to a wall outlet. A software first simulation driven workflow solves this. Our goal is to shift development from traditional hardware first software later model to a collaborative parallel flow where software informs hardware decisions. Hardware features can be evaluated instantly using virtual models. AI workloads can be tuned throughout the product development life cycle. Updates can continue over the air long after development while teams have pivoted onto next generation designs. Instead of having two disconnected flows, we now have one integrated development loop. That's how modern platforms are built, and that's how we help customers win. That's how you collapse schedules instead of extending them. We build Atlas Explorer to deliver deep visibility and software first introspection, Whether that's machine mode versus supervisor mode versus user space execution, whether it's multi threaded execution behaviors, whether it's per HART performance, or identifying memory bottlenecks that are very, very difficult to reproduce. When you know how your software behaves, you know how your hardware needs to be built. Customers often ask about porting their software stack. Truth is, this can be scary, but in most modern code bases, 99 of the code is CC plus plus configuration files and build scripts. That's all handled by compilers and tool chains. This means less than 1% of code tends to be architecture specific. So a typical SDK of one and a half million lines of code might only require modification to about 1,500 lines. Tools cover the rest. And when they don't, we provide design services for the parts that need some extra help and attention. We've migrated architectures. We're here to support you too. We can look at a bigger example, like bringing up a Linux distribution on RISC five. When communities come together with a common goal, amazing things can happen. While a lot of early work for the RISC five port was started in the Fedora community, when the Deviant teams finally decided to bootstrap RISC five, they had 80% of the user space libraries and applications building and passing tests in less than two months. That's over a billion lines of code building and testing in less than two months. Software migration is no longer a blocker. It's a solved problem. And for customers who need deeper levels of support, we cover that too. Pre silicon software development, RTOS and SDK replacements, architecture migrations, CV and security updates, long term maintenance and support. A tier one customer of ours has said it best. With periodic updates from MIPS, our products are more secure. This is the kind of partnership we aim to build. We aim to build long lasting, tried, trusted, and true partnerships. And we can do this well because our SDK technologies largely overlap with what our customers deploy in production at scale. Whether it's GNU and LLVM tool chains with MIPS defined extensions and optimizations or virtual platforms to shift left software development and hardware software co design, we engage early with Atlas Explorer for performance tuning and workload optimization. In terms of SDKs, we support embedded Linux that's optimized for fast boot and coherent SMP execution. Of course, there's our task support, secure boot, secure monitors, trusted execution environments, and multithreading. A full edge AI inferencing stack is also supporting CNNs, DNNs, LSTMs, transformers, LLMs, and graph transformation with optimized kernels. This means you can bring your own model from Onyx, PyTorch, or TensorFlow and deploy on these devices. This is a complete software development and optimization environment built on either the latest technologies or technologies that have become well established in the industry. Our technology choices are intentional. They're not an afterthought. So let me reemphasize some earlier points on the future being based on open standards. Our risk five cores are open, modular, extensible, and workload tuned. What does this mean for customers? It means that customers get a standardized programming model, application specific instructions, and workload focused performance, and, of course, support from the best of the commercial and open source software ecosystem. Exactly what modern edge platforms need. Because these days, no one builds in isolation. Like many, we tried, and it worked for a while, but we missed the key ingredient, the scale that comes from software developers building on your platform. Because of the common risk five base, our platform seamlessly integrate with the ever evolving ecosystem landscape. So we take our learning, our heritage, and use this to accelerate the risk five ecosystem, not just by ourselves, not just with customers, but with software developers across the globe, whether they're building on our platforms or not. This is how innovation scales. So if we look at how our CPYP families enable the autonomous edge across four major domains, we start with the m 8,500, a real time 32 bit MCU. This is used in transportation, robotic control loops, and power management systems. It's got microarchitectural optimizations and ISO level extensions for motor control and digital power systems. Our I 8,500 is a 64 bit data orchestration processor, ideal for zoneal gateways, industrial networking, SSD controllers, and the like. Here, we focus on microarchitectural optimization for moving data and control plane functions. Our p 8,700 is for data movement and IO intensive compute. Out of order execution, 64 bit, multi core, multi threaded, and functionally safe. Finally, the s 8,200 AI accelerator. This is the latest processor that we announced, perfect for transformers and large language models, but also really accelerate CNNs, DNNs, LSTMs, and more. This portfolio forms the basis of physical AI at the edge. And it doesn't end there. We recently announced combining with the Synopsys Arc processor IP solutions business. This strengthens our engineering talent, our product offering, and our ability to deliver AI driven RISC V IP at scale. Our remission remains unchanged. Enable autonomous edge devices with AI cores, risk five IP, and software guided intelligence at the platform level. This strategy positions us for high growth opportunities across transportation, robotics, industrial, and embedded AI applications. Let me close with this. Physical AI, embedding intelligence into the devices that are all around us is no longer theoretical. It's happening today. And MIPS plus GlobalFoundries are building the foundation, and this is how we're doing it. Software guided intelligence forms the basis for hardware software co design. Ultra efficient IP portfolios enable customers at scale. Investing in open standards and enabling global innovation. That is risk five at foundry scale. And this is our mission, to enable open, standards based platforms our customers want to build, platforms that are defining the future of transportation, robotics, and the intelligent edge, systems that we have not yet even imagined. Thank you for your time. Please reach out at mips dot com or info@mips.com if you'd like to explore how we can build your next platform together or connect with me after this talk on LinkedIn. I think at this point, we now have some time left over for q and a. Thank you very much, Sam, for an excellent presentation, and thanks to our, our audience. We're moving on to the q and a, portion of the event, so this is a good time to submit any questions to the presenter. But before we do that, Sam, I can ask you a couple of questions. You mentioned that less than 1% of code is architecture specific. For teams that are still hesitant about migrating to risk five, what's the biggest concern you hear, and how do you address it? Yeah. Yeah. Great question. So in many cases, it's not so much about the code anymore that causes the concern. There might be, knowledge of ecosystem support or, supply chain components that, that our customers rely on. You always find yourself in conversations where, you know, do you have this instruction or do you have this intrinsic? Do you have this functionality? Mhmm. But but for for for the world to run, software first as it has for for many, many years, you know, we've we've written in in higher level languages, and we use tools to do a lot of that translation. So, and to answer specifically. And in most cases, it's just being familiar. Rescribe is is different. We all know what we know. And so it's, mostly a case of encouragement, going to spend some time to, learn and explore, what's out there. Okay. Thank you. With, with Atlas Explorer with the Atlas Explorer simulation environment, how early in the program can teams start making hardware decisions based on software insights? You know, what does that workflow really look like? Yep. So so the so the workload is quite interesting. Right? So the building microarchitectural models of your processor pipelines means that you can actually run the workload and see the estimated performance, before you've even started building, the system or integrating the system. And and and so what I like to say is look, the model's right until the the RTL's raw, created. And and at that point, you you converge along the way. So what. it means is you get to explore different trade offs and you get to do it in a very, I would say meta metadata driven way. So, exploring, trialing, and really tuning your systems, is possible. And again, this this happens, and is facilitated via via simulators, well before the the hardware teams have actually, penciled up any VHDL or marijuana. K. Couple more questions for you here. The Synopsys ARC acquisition was recently announced. Right? How does does I mean, does that change or expand what MIPS can offer customers in the near term? I mean, so so so near term pre closing, no. I mean, regulatory reasons and and all the others. But but, you know, looking forward to to that completing, it does mean that, yes, you know, teams are expanded, portfolios are expanded, and you start to actually have a larger, you know, center of gravity, in terms of, you know, stable company, you know, very, seasoned teams coming together to really push the industry forward in this direction. Okay. Great. So, how has, the risk five, ecosystem matured over the past couple of years from your vantage point? I would say I'd say quite well and and with a lot of enthusiasm. Right? So there's there's there's something around the the the concept of openness, right, that that brings people together. Right? So it's not just, you know, players who are in the industry or who have a have a product or a or a or a business need to do something, you get a lot of you harness the ingenuity of humanity. Right? People curious about computer architecture, whether it be in education systems or whether it just be curious people wondering how things work. The access to, the the standard, the access to the communities who are who are building this is is accessible. And and so, what it means is you get a very, inclusive environment for anybody to, K. engage and to participate. So, we had I would say if we look at other ecosystems and and the and the time that it's taken to to grow or to become, applicable or relevant to particular market segments. The openness and and and the just the the the the strategy of ascribe in general, the modularity and so on just accelerates all that. Gotcha. I'm gonna shift to audience questions here. So. Nilesh in the audience mentioned, said you mentioned that most software is portable across architectures. What are the biggest hidden challenges when migrating embedded AI applications to a new platform? Yeah. Very yeah. Good point. So, when you move across any platform, you know, you know, step one doesn't work. Right? And so, we're getting a lot better. The industry is getting better at making that possible. You know, the next thing is, you know, is it functionally correct? If I ran it on one system and I moved it to the other, do I get the same results? Do I get the same probability? And and as you start to peel that onion further, you start to find out, okay. Well, this hardware, you know, handled, you know, some bits differently and some floating point operations. Was it compliant with I triple e? Was it, optimized for some other fast paths to to optimize? And and so you if you start from does it work and then you start from is it correct and then you move on to how well does it run. Think about it as an onion and you just keep feeling those layers and, ultimately, the act of doing so, doesn't doesn't take all that much work. You know, but that's that's the word that, the world that we all live in as engineers. You know, getting it to that point where you feel comfortable at the end of the day that, it it ticks all the boxes and and meet your requirements. Great. Well, we have another audience question I'm gonna ask. Is the s 8,200 based on, any open risk five AI standard, or is there or is there something closed? So so it is a it is a risk five, based processor. So it has a, an RVA 23 scalar, and vector unit and, the the vector attached to matrix extension. So so what makes it quite interesting is that it is a single pipeline and it is fully built on RISC V. And and and so what that means is that a lot of the tools and the runtime and and other aspects of the software stack, you know, the the standards already exist. Others are able to collaborate. And so while, you know, micro architecturally, there's lots of work that we still have to do and are doing. It it puts us in a very nice position to collaborate more more broadly with, software developers and customers who, also see, some of the challenges with proprietary architectures solving similar problems. Thank you, Sam. It looks like we've got another question from Nilesh. So how, how do virtual platforms ensure accurate accurate real world performance? Yeah. That's a great question. So so so in some cases, the the virtual platforms are are are are modeled to give you the correct answer. Right? We we call it the the state accurate, instruction accurate, behaviors of what what the hardware would do. Right? Now, from that alone with some static and heuristic based, methods, you can you can get rough estimations of performance and so on. But but but to really unlock that next level of detail, that's where, having microarchitectural models available for those pipelines or for those processors, will give you the show you the interdependencies and pipeline stages or instruction, you know, waiting on memory and barriers, coherency and the like. And so that's a a fairly novel thing that that we do to engage, with with the software teams. And again, the earlier we can see that, the earlier we can make good decisions, both in the hardware or also, you know, prepare software, for the hardware well in advance. What that means is when the when the hardware is done and if the software is done at the same time or before, we're all moving on together to iterate on the system the next time around rather than dealing with the burden of bringing up the software, because we're all behind and late. Okay. I think we'll have we have time for a couple more questions. We've got, Eunice from the audience, asking, do you think open source architecture, namely RISC V, will overtake architectures like ARM in the next few years in terms of popularity. I had yes. I hope overtake, in particular markets, you know, maybe in for sure. As mentioned, I think in a previous question, right, there's from the computer architecture level, it's, you know, everybody can engage and get involved, but but that doesn't at all, you know, mean that I'm a great company and, you know, very well established in this space and shipping lots of products and lots of different domains. And so, you know, you you always have this, tension or this balance, which is, you know, how do you spend your time? So at work, you're, you know, building and working on products that, you know, meet company objectives or or solve, particular problems. You might also, you know, be generally curious about, you know, how you make things better. And so, I think you'll you'll most certainly see particular segments of the market, start to go pivot, in one way or the other. But but fundamentally, so many of these systems are are gonna end up being heterogeneous just, in terms of optimizing or specializing compute where it needs to happen. And and so, you know, we we've seen this for, you know, over ten years now. You know, armed systems, you know, coupled or connected with those five systems is, happens and and is is very much kind of status quo at this point. So don't know about overtake in general, but but most certainly, you know, both have their places and, you know, solve a lot of solve a lot of problems and needs that customers and and engineers have. Great. I think, you know, I think that's about all the time we have for questions today. I I really appreciate it. Thank you very much, Sam, for the excellent q and a. and presentation, and thank you to our audience. Your time is very valuable to us. So thank you very much, Sam. Yep. And I. Thank you. no problem. I I look forward to seeing everyone else at the next session with, intelligence on the edge. Thank you.