<p id="isPasted">For most of the last decade, AI's biggest breakthroughs have involved large data centers and cloud infrastructure. But a more consequential shift is happening at the same time: <a href="https://mips.com/markets/physical-ai/" target="_blank" rel="noopener noreferrer">Physical AI</a>. Intelligence is increasingly embedded directly into physical systems that must act instantly in our unpredictable world, requiring a fundamentally different approach to compute than traditional cloud or data-center AI. </p><p>These systems must respond to changing conditions, often in real time, with software decisions that carry real-world consequences. A warehouse robot spotting an obstacle or identifying a load too heavy to lift, or a vehicle detecting a pedestrian stepping into its path, must process that information locally within strict timing constraints while balancing performance, power, safety, reliability, and cost. </p><p>That creates a challenge for developers. Physical AI systems need capable hardware, but "capable" is difficult to define in isolation. Standards need to support different workloads, software has to inform hardware design, and developers need platforms built around target workloads. Each layer depends on the other: software, architecture, standards, and developer tools all have to work together. </p><p>That's the premise behind MIPS' approach: a continuous feedback loop, in which developer needs and workload insights shape the standards, architectures, and platforms that come next. </p><h2>Starting with Open Standards</h2><p>Physical AI introduces new requirements around real-time performance, deterministic execution, safety, efficiency, and workload-specific optimization. As a result, architectures must evolve alongside emerging application demands. For many design companies, participation in an open standards ecosystem provides valuable visibility into how the industry is addressing these challenges, from evolving workloads and software requirements to the needs of developers and system designers. This insight helps inform how architectures and broader ecosystems must evolve to support the next generation of intelligent systems. </p><p>In 2021, MIPS announced its decision to embrace RISC-V as the architectural foundation for its next generation of compute solutions. This gave the company an open, flexible foundation on which to build differentiated processor architectures and workload-focused technologies while participating in a broader ecosystem that can help accelerate innovation across Physical AI and other emerging computing markets. </p><p>More than five years later, MIPS remains deeply committed to RISC-V, highlighted by its recent elevation to Premier Member of RISC-V International. MIPS CTO Yankin Tanurhan also serves as vice chairman of the organization, further strengthening MIPS’ role in shaping the RISC-V ecosystem and supporting its position in the Physical AI market. While anyone can build on RISC-V, Premier Membership gives MIPS a seat on the organization’s technical committee, providing a direct role in influencing the evolution of the standard itself. MIPS is now active in several committees, task groups, and Special Interest Groups (SIGs) spanning automotive, functional safety, security, crypto, vector processing, and documentation.</p><h2>Turning Standards into Hardware</h2><p>Open standards deliver value when they can be translated into hardware that meets developer needs. MIPS' influential position in the ecosystem helps inform its development of RISC-V-based processor IP and microarchitectures around specific workload characteristics, connecting broader architectural standards with the demands of real-world applications. </p><p>At the microarchitecture level, workload characteristics begin to influence actual hardware decisions: what needs to run efficiently, where a few extra watts of power budget is critical, where latency matters, and how processing tasks are divided internally. For example, workloads that require continuous multi-sensor perception with strict latency constraints may benefit more from tightly coupled memory and efficient data movement than from higher clock speeds alone. </p><p>The MIPS <a href="https://mips.com/products/s8200-series/">S8200</a>, a RISC-V-based NPU, illustrates this workload-focused approach. Designed around the distinct characteristics of AI inference at the edge, it addresses the need for high-throughput parallel data processing within strict power, thermal, and latency constraints. These considerations are particularly important for edge devices operating on minimal AC power or batteries. In applications such as autonomous vehicle steering, for instance, efficient inference can help systems process sensor data and respond to changing conditions within tight timing requirements. MIPS designed the microarchitecture's execution unit and memory interfaces around these software behaviors, tailoring the hardware to the demands of edge AI inference. </p><p><span class="fr-img-caption fr-fic fr-dib fr-draggable"><span class="fr-img-wrap"><a href="https://mips.com/acies/" target="_blank" rel="noopener noreferrer"><img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNzkyNTkxNjMxNzczLU1JUFMjMy5wbmciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width:419px" class="fr-fic fr-dib" /><span class="fr-inner">MIPS Acies platforms. Source: MIPS.</span></a></span></span></p><h2><br /></h2><h2><br /></h2><h2><br /></h2><h2><br /></h2><h2><br /></h2><h2>From Processor IP to Workload-native Platforms</h2><p>Developers need more than hardware to translate Physical AI models into real-world systems. Independently sourcing, integrating, and testing every layer of software, networking, and processor IP can also create unnecessary friction. </p><p>To bridge this gap, MIPS packages its custom RISC-V processor IP into three workload-native Physical AI platforms, which the company launched in September 2026: <a href="https://mips.com/press-releases/mips-launches-workload-native-platforms-for-physical-ai/" target="_blank" rel="noopener noreferrer">Acies, Actus, and Aegis</a>. These frameworks allow developers to build around the specific workloads and requirements of their applications. </p><ul><li><p><strong>Acies:</strong> An inference-native platform for modern edge AI workloads, combining an open, standards-based NPU with an open software stack</p></li><li><p><strong>Actus:</strong> An event-native platform for real-time embedded applications such as motion control, sensor fusion, and predictive maintenance</p></li><li><p><strong>Aegis: </strong>A safety-native platform for mission-critical Physical AI systems requiring low latency and agentic processing</p></li></ul><p>While these platforms address different workload characteristics, they all share MIPS’ broader software-first, open, and modular approach. As MIPS CEO Sameer Wasson explained, "<em>MIPS is driving this shift with open, software-first platforms that give customers a common foundation to build, customize, and deploy Physical AI, with efficiency and tokens-per-watt as the foundation of our technology.</em>"</p><p>Acies, Actus, and Aegis are also production-ready environments designed to support commercial and ecosystem development. A unified software stack, combined with microarchitectures built around specific workload profiles, helps developers scale quickly from prototype to production without having to build software from scratch. </p><h2>The Software Layer Closes the Gap</h2><p>Physical AI workloads evolve rapidly and may combine traditional embedded processing with AI inference, real-time sensing, and other complex functions. At the same time, hardware decisions establish limits on compute power, memory bandwidth, thermal performance, and other critical capabilities. If software isn't considered earlier in the hardware development process, developers risk designing systems around assumptions that don't hold once the software is running. </p><p>MIPS' workload modeling and tools, such as Atlas Explorer, give developers earlier visibility into how software and models will behave on prospective hardware. Engineering teams can create digital twin models that run actual workloads on virtual RISC-V compute subsystems, allowing them to predict latency, instruction execution, and data flow. This environment enables teams to co-design hardware and software from the outset rather than treating software as something that comes after the silicon is finished.</p><p>The software-first approach supports system-wide optimization. Developers can pinpoint where a complex blend of sensing and inference creates a bottleneck and identify exactly where the workload may benefit from specialized acceleration. The same modeling environment can reveal where hardware resources aren't being fully utilized, helping engineers make micro-architectural adjustments that can maximize edge metrics like tokens-per-watt.</p><h2>Enabling the Ecosystem, Not Just the End Product</h2><p>For RISC-V and Physical AI to reach their full potential, the broader ecosystem - including software developers, semiconductor designers, OEMs, integrators, standards organizations, and other technology partners working around the same architecture - needs open, accessible platforms it can build on, experiment with, and customize. </p><p>MIPS provides rich developer environments and platforms that allow the ecosystem to rapidly prototype, test ideas, and iterate long before committing to production. This approach is supported by a portfolio covering the core layers of the design cycle: processor IP, software and modeling tools, application-specific/custom silicon, and Physical AI platforms. GlobalFoundries (GF) complements these capabilities with process, packaging, and manufacturing expertise.</p><h2>The MIPS Feedback Loop</h2><p>MIPS connects open standards, hardware architecture, software, and developer platforms into a continuous feedback loop for Physical AI. Each layer informs the next, creating an iterative development process rather than following a linear path from standards to chips to products. </p><ul><li><p><strong>Standards: </strong>MIPS contributes to the development of open standards and the architectural foundation for the ecosystem. As developers encounter new edge-processing requirements, those needs can inform the evolution of the RISC-V ISA through industry participation. </p></li><li><p><strong>Microarchitecture: </strong>MIPS translates architectural standards into processor designs optimized for specific workloads.</p></li><li><p><strong>Platforms: </strong>MIPS packages these capabilities into workload-native platforms and development tools, giving developers an environment to build, test, and customize solutions for real-world applications. </p></li><li><p><strong>Developers and ecosystem: </strong>Developers use the platforms, identify new requirements, and provide feedback through real-world workloads and applications.</p></li><li><p><strong>Back to standards and hardware: </strong>That feedback informs future architectural, hardware, and platform development.</p></li></ul><p>This continuous feedback loop is critical for Physical AI, where perception, reasoning, and response may need to happen simultaneously under strict power, latency, reliability, and safety constraints. An autonomous vehicle or industrial robot, for example, may need to process sensor inputs, run transformer inference, and execute safety-critical motor control within the same system. The underlying computing architecture must accommodate these combined requirements as software and workloads evolve. </p><p>The result is a tighter connection between software requirements and hardware development. Developers gain a more direct path from ideas to working systems, enterprises can reduce friction on the path to production, and Physical AI systems can be optimized around the workloads they need to run in the real world. </p><h2>What This Could Mean for Physical AI</h2><p>As AI moves beyond the cloud and data centers into the physical world, it will span different combinations of workload characteristics and deployment environments. From robotics and automotive to industrial and other embedded systems, the next generation of Physical AI will require architectures that accommodate a wide range of processing requirements. </p><p>These systems will demand compute that is configurable enough to adapt to rapidly changing workload combinations, while still satisfying real-world constraints around efficiency, latency, safety, and reliability. </p><p>Meeting these challenges at scale requires industry-wide adoption of open, software-first development models. Software must be co-designed alongside hardware so technology partners can build and adapt computing infrastructure faster and with greater flexibility. MIPS’ workload-native platforms provide an example of how the industry can move from broad architectural standards toward more application-aware computing platforms.</p><p>The success of the <a href="https://mips.com/products/software-01/" id="isPasted" target="_blank" rel="noopener noreferrer">next stage of RISC-V development</a> will depend not only on defining architectures or adding new extensions, but on building an environment where developers can readily build, test, and deploy systems that can navigate real-world constraints safely and efficiently. </p>

From Open Standards to Workload-native Platforms

Building the Feedback Loop for Physical AI

<h2 id="isPasted">Software Is Driving The Conversation</h2><p>Specialized workloads are changing how compute platforms are designed. Systems built for physical AI must process growing volumes of sensor data locally while meeting strict requirements for latency, power, safety, security, and deterministic response. These demands make the workload and its software requirements an essential input to processor, platform, and silicon decisions.</p><p>Software can no longer enter the process only after the hardware is complete. A software-first approach begins with the application, representative workloads, response requirements, data movement, memory behavior, safety goals, and system constraints. Hardware and software teams use that evidence to shape the compute architecture before costly implementation decisions are fixed.</p><p>The design question becomes: Which combination of general-purpose compute, specialized acceleration, memory, interfaces, and software best satisfies this workload’s measured requirements?</p><h2>What Happens Beneath The Code Matters</h2><p>Software defines what a system needs to compute. While developers can optimize algorithms and applications, the underlying processor architecture and IP ultimately determine how effectively that software executes. For instance, a workload that relies heavily on matrix multiplication can run on general-purpose hardware, but doing so can result in significantly higher latency and power consumption.  </p><p>A mismatch between a workload and the selected architecture becomes increasingly expensive to correct as the design moves from architecture definition into RTL, verification, and fabrication. Software teams can mitigate some limitations, but they cannot recover capabilities, data movement efficiency, or acceleration resources that the hardware does not provide. A software-first approach brings workload evidence into earlier decisions and gives developers visibility into how the proposed architecture behaves.</p><ul><li><p>Where performance bottlenecks occur</p></li><li><p>How workloads map to hardware</p></li><li><p>Which functions can benefit from specialized acceleration</p></li><li><p>How software decisions affect power and latency</p></li><li><p>Where hardware changes could deliver meaningful gains</p></li></ul><p>These insights allow developers and silicon designers to optimize the path from software requirements to silicon implementation. In the matrix-multiplication example, workload analysis could show whether the best response is a more suitable CPU configuration, a standards-based NPU, a DSP, or a custom programmable accelerator. That evidence supports an architectural decision before implementation cost and schedule are committed.</p><h2>From Software Running On Hardware To Software Shaping Hardware</h2><p>Traditionally, hardware and software have followed a largely linear relationship: Hardware is designed first, and software is developed and optimized to get as much performance as possible from an already defined architecture. When a workload runs inefficiently, developers can only optimize the applications and algorithms to fit the available resources. </p><p>A software-first approach creates a continuous design loop: workload, measurable requirements, platform architecture, processor and accelerator choices, silicon implementation, and software optimization. Each pass through the loop produces evidence that can refine the next architectural decision.</p><p>Workload requirements shape software, which in turn informs the architecture and IP design before everything is integrated into silicon. Once an accurate model is available, developers can test workloads against the real architecture and optimize software accordingly. Insights from those workloads can feed back into architectural decisions, creating a continuous feedback loop. The result is an ecosystem where software becomes an input into hardware decisions rather than simply an end product of them. </p><h2>Open Architectures Change Who Gets To Participate</h2><p>Open architectures separate the instruction set architecture, or ISA, from the processor implementations built on it. RISC-V combines a standard base instruction set, optional standard extensions, and reserved encoding space for custom instructions. For developers and system architects, meaningful visibility comes from the models, tools, documentation, and performance data that show how software behaves on a specific implementation. That evidence can support standards-based software reuse while informing workload-specific extensions and microarchitecture choices.</p><p>The value comes from connecting the people who develop software with the people who define hardware. When workload analysis exposes a bottleneck, both teams can evaluate whether software optimization, a different processor configuration, a standard accelerator, or a custom extension offers the best response. Open standards provide a common foundation for that collaboration while preserving room for differentiated implementation.</p><h2>Why This Matters For Physical AI</h2><p>Physical AI makes this relationship particularly important. A robot, autonomous vehicle, or industrial system has to sense, process, decide, and act, often under strict power, latency, and safety constraints. A single system may combine signal processing, neural network inference, and real-time control loops, with each workload placing different demands on the underlying compute. Industrial and automotive systems also expect to meet functional safety standards that can demand deterministic behavior. </p><p>Those requirements can't always be addressed effectively through software optimization alone. Developers can only optimize algorithms and applications so far before the underlying architecture limits them. Even the most efficient software can't reduce power consumption below what the hardware allows or add components the silicon doesn't have. The architecture itself needs to reflect the characteristics of the workloads it's designed to execute. </p><p>Workload-native computing applies this method at the platform level. MIPS begins with the behavior and constraints of a target workload, then combines processor IP, acceleration, virtual models, software tools, reference silicon, and development hardware into a practical evaluation target. Its three workload-native platforms address distinct needs: <a href="https://mips.com/press-releases/mips-launches-workload-native-platforms-for-physical-ai/">Acies for inference-native AI, Actus for event-native real-time control, and Aegis for safety-native application processing</a>. Each gives developers an earlier environment for software bring-up, workload testing, performance analysis, and ecosystem development.</p><h2>The Developer Becomes Part Of The Hardware Conversation</h2><p>The larger shift is cultural as much as technical. Developers have traditionally consumed hardware platforms. They typically worked within whatever architecture they were handed, even though they often have the clearest view of how real workloads and systems behave in practice. </p><p>In a software-first model, developers contribute measurable workload evidence to architecture and IP decisions. Application behavior can reveal instruction mix, data movement, cache and memory pressure, concurrency, latency, and acceleration opportunities. Hardware and software teams can use those findings to select processor classes, configure subsystems, define custom instructions, and identify the work best assigned to CPUs, DSPs, NPUs, or application-specific accelerators. The same evidence then guides software optimization and the next design iteration.</p><p>That loop can ultimately produce more differentiated and optimized systems. When the hardware is built around specific workloads, it delivers the performance, efficiency, and specialization that Physical AI computing demands. </p><h2>Software-To-Silicon Becomes The New Design Loop</h2><p>Software and hardware now operate as parts of one continuous design process. Workload requirements shape the architecture, measured software behavior informs processor and accelerator choices, and performance observations guide the next generation of platform development.</p><p>Physical AI systems operate within strict limits for power, latency, safety, security, and availability. They often combine perception, inference, control, and communications workloads on one platform, making the relationship between software requirements and silicon implementation especially important. RISC-V processor IP, configurable acceleration, and pre-silicon virtual models give teams practical ways to evaluate those tradeoffs earlier.</p><p>Companies that connect workload analysis, software development, processor IP, platform engineering, and silicon implementation can make architecture decisions earlier and validate them against real applications. That capability reduces late discovery of performance and integration problems, preserves more design flexibility, and creates a clearer path from workload requirements to production-ready physical AI systems.</p><h2>Conclusion</h2><p>Software-first development gives developers greater visibility into the architecture beneath their code and brings workload requirements into hardware decisions while those decisions remain changeable. Developers can evaluate representative workloads on virtual models, identify performance and efficiency constraints, and work with hardware teams to select or shape the right compute resources. The result is a continuous software-to-silicon design loop built on measured behavior.</p>

Why Developers Need Visibility into the Silicon Beneath Their Code

The Software-First Shift

<p id="isPasted">Physical AI is one of the fastest-moving fields in engineering today, and it presents significant design challenges for engineers. </p><p>Whether in robots, driver assistance systems, or factory equipment, Physical AI platforms need sufficient compute to sense the physical world, process data, and make decisions in real time. Physical AI combines both AI inference with real-world interaction and closed-loop control. The systems must act locally and make decisions immediately in order to perform the required actions. The challenge is that designers usually source processor IP from one vendor and manufacture it with another. When neither supplier is accountable for the combined result, teams can end up with over-provisioned or unoptimized chips that leave performance, efficiency, and cost on the table.</p><p>In August 2025, GlobalFoundries completed its acquisition of MIPS, giving MIPS unique access to a foundry and setting it apart from the rest of the IP market. As the #2 IP provider overall and the leader in RISC-V IP, <a href="https://www.wevolver.com/article/how-mips-is-powering-physical-ai-with-risc-v-and-software-to-silicon-development" target="_blank" rel="noopener noreferrer">MIPS goes beyond licensing processor IP alone</a>—delivering software tools, custom solutions, and complete platforms alongside GlobalFoundries' differentiated process technologies and manufacturing capabilities. Now, chip design teams can leverage that combination to develop Physical AI designs from concept through production.</p><h2>Silicon Challenges for Physical AI</h2><h3>Timing Constraints</h3><p>When <a href="https://mips.com/markets/physical-ai/">designing Physical AI systems</a>, one challenge is achieving fast and consistent response. In the real world, a delayed result can mean the difference between life and death, making timing a first-order design constraint. For example, a braking controller or robotic arm can't tolerate variable interrupt latency because the control loop depends on predictable timing, and the silicon must consistently meet those timing requirements. </p><p>But improving latency isn’t as simple as using an accelerator, as designers do in data centers.  AI accelerators tend to optimize average throughput above all else and leave worst-case response time unbounded. In data centers, that trade-off is acceptable because an occasional slow result only means a user waits slightly longer. In Physical AI systems, however, response consistency matters more than average speed. Consider a warehouse robot detecting a worker in its path: if its processor meets the deadline 99 times but misses it once, the robot may collide or injure a human. Engineers therefore need deterministic compute that responds at a defined interval on every cycle, not just on average.</p><h3>Power and Thermals</h3><p>Beyond timing, designers are limited by power constraints in edge systems. First, the portable nature of many Physical AI systems means they often rely on battery power, limiting the energy available for computation. Meanwhile, many real-world systems require fully sealed enclosures, where passive cooling may be the only practical option. Designers must therefore balance minimal power consumption with limited thermal headroom while supporting demanding on-device AI workloads.</p><h3>Certification and Longevity Requirements</h3><p>In highly regulated industries such as automotive, aerospace, and industrial, customers need functional-safety evidence that extends down to the device’s processor architecture and its development process. To this end, the processor IP needs to come with the documentation, evidence, and safety capabilities required to support the system-level safety case. </p><p>Meanwhile, these stringent markets can also entail extremely long product lifecycles. OEMs in these markets expect products and components to remain available for over a decade on average. When a processor changes mid-life, engineers often need to repeat qualification and safety certification, adding significant cost and schedule risk.</p><h3>Mixed Workloads</h3><p>The final challenge in designing Physical AI systems is handling the mixed workloads inherent to such applications. Systems like humanoid robotics rely on both real-time control and AI inference in the same system. However, these workloads have different architectural requirements: control logic depends on predictable latency, while AI inference depends heavily on raw throughput.</p><p>For example, to keep a humanoid robot balanced, engineers typically program its joint controllers to update motor commands at fixed intervals, often thousands of times per second. A late update, even by a fraction of a millisecond, can destabilize the robot’s gait. Meanwhile, the robot’s vision model must process camera frames to recognize objects, where overall throughput matters more than the timing of any single operation.</p><p>In that context, optimizing a core for one workload can compromise the requirements of the other.</p><h2>From IP Vendor to Foundry</h2><p>Design teams need to decide on an instruction set architecture (ISA) and an IP vendor early, then choose a foundry later. These decisions significantly impact the final chip's power, performance, and area (PPA). Yet teams often make them before anyone can evaluate the processor IP’s behavior on the specific manufacturing process ultimately selected.</p><p>Foundries are typically manufacturing providers, entering the conversation only after the architecture is fixed. Unfortunately, that split creates a gap in accountability because no single supplier is accountable for the combined result if the IP reaches silicon and underperforms. The IP vendor may point to the process, while the foundry may point to the microarchitecture, leaving the design team to absorb the resulting cost and schedule impact.</p><p>Meanwhile, licensing terms further narrow the options. Teams licensing a proprietary ISA end up paying more with less flexibility to customize the underlying microarchitecture, making it harder to tune the core against a specific PPA target. To correct a PPA shortfall after tapeout, teams can order a silicon respin that takes up significant time at a point in the program where schedule pressure is already highest.</p><h2>Platform-Level Silicon Partners</h2><p>Chip designers can avoid these issues if they can work with one supplier that brings processor IP and manufacturing capabilities together. By owning both processor IP and process technology, suppliers can tune PPA holistically, treating the core and the process as a single optimization target rather than two fixed inputs. Design teams can then predict a core’s behavior on specific processes earlier in the design cycle, moving the PPA question out of post-tapeout measurement and into the architecture phase.</p><p>One accountable supplier can also help design teams meet power or die-area requirements. When a design comes in over budget on either, the team has one partner that can evaluate changes to the microarchitecture, process technology, or both, instead of two vendors negotiating around a shared problem.</p><h3>Providing an Extensive Processor IP Portfolio</h3><p>When selecting a supplier, another factor to consider is their ISA.</p><p>For instance, a supplier using an open ISA such as RISC-V can give design teams greater architectural flexibility without requiring them to license a proprietary ISA. Open ISAs also attract a community of vendors, universities, and independent tool developers, giving design teams access to expertise beyond the IP supplier's own support engineers. The same community supplies a growing foundation of tools, reducing dependence on a single vendor's roadmap for compilers, debuggers, and verification collateral.</p><p>For Physical AI designs, an open ISA’s architectural flexibility helps teams address several of the challenges outlined earlier. Vendors can layer optional extensions, such as vector and matrix instructions, on top of a shared base instruction set. As a result, engineers can build deterministic control cores and AI inference engines on the same ISA foundation. </p><p>Teams can also add custom instructions to accelerate specific control or AI functions, trimming the power and die area a general-purpose core would waste. That independence from a single vendor’s roadmap also matters for longevity, letting teams better sustain their software investment across the decade-plus lifecycles of automotive and industrial products.</p><h2>Pre-Silicon Workload Modeling</h2><p>Finally, portfolio breadth and flexibility help only if a team can easily evaluate its options. In practice, engineers need tools that can model real software on candidate hardware configurations before tapeout because it’s far less costly to identify a bottleneck in simulation than in tapeout, when addressing it may require a silicon respin. </p><p>By working with suppliers that offer accurate simulation and modeling tools, teams can properly tailor a core to their workloads without wasted power or die area. In turn, they can reach the foundry with greater confidence and less design risk. </p><p><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790370357999-1790370357999.png" width="624" height="156" class="fr-fic fr-dii" /></p><p><br /></p><h2>The Case for GlobalFoundries</h2><p>Following GlobalFoundries acquisition of MIPS in August 2025, the combined company became the ideal supplier for chip designers. Now offering both manufacturing and processor IP, as well as software tools, custom solutions, and complete platforms, GlobalFoundries can deliver differentiated solutions for energy-efficient edge computing.</p><p>With access to both halves of the design equation, GlobalFoundries engineers can uniquely optimize PPA earlier in the design cycle, before register-transfer level (RTL) code freezes. And because GlobalFoundries already serves automotive, IoT, and communications infrastructure – the same segments MIPS cores target - the process technology and the core portfolio point at the same customers. For example, an automotive tier-one supplier asking for a safety-certifiable core on a qualified automotive process can now get both specified by the same engineering team.</p><h2><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790370358004-1790370358004.png" width="624" height="113" class="fr-fic fr-dii" /></h2><p><br /></p><h2>The MIPS Atlas RISC-V Portfolio</h2><p>On the portfolio side, MIPS built its Atlas compute subsystems primarily around the open RISC-V ISA. This approach gives design teams the flexibility to develop differentiated compute platforms without purchasing a proprietary architecture license. With ARC processors now part of the portfolio, Atlas encompasses a broad range of embedded processors, application processors, neural processing units (NPUs), and digital signal processors (DSPs).</p><p>MIPS organizes its Atlas subsystems around four roles within a Physical AI platform: Sense, Think, Act, and Communicate. This framework reflects the distinct compute requirements involved in enabling real-time intelligence at the edge.</p><ul><li><p><strong>Sense</strong> covers capturing and moving data from cameras, radar, lidar, and other sensors. This step demands high-bandwidth data handling and signal processing, often through DSPs.</p></li><li><p><strong>Think</strong> covers AI inference and decision-making, where designers deploy NPUs and vector-capable cores to interpret sensor data, perceive the environment, and plan the next action.</p></li><li><p><strong>Act</strong> covers real-time control of motors, actuators, and batteries, where embedded processors must execute control loops deterministically and often meet functional-safety requirements.</p></li><li><p><strong>Communicate</strong> extends the platform to connectivity and communication workloads, such as in-vehicle and industrial networking, helping complete the closed-loop architecture required by Physical AI systems.</p></li></ul><p>Within the Act role, the Atlas portfolio now spans multiple safety-capable processors for automotive and industrial designs, including safety-certified cores from the ARC family. For example, MIPS’ M8500 provides event-driven, low-latency control-loop processing for robotic movement. The subsystem also provides certifiable functional safety that meets automotive and industrial requirements. Customers are already designing these processors into vehicles. For instance, <a href="https://mips.com/press-releases/mips-drives-real-time-intelligence-into-physical-ai-platforms/">MIPS expects a customer automotive platform based on the M8500 to enter production in 2027.</a></p><p>Even though GlobalFoundries offers both manufacturing and IP, customers can still keep fab commitment separate from the IP decision. As a standalone business inside GlobalFoundries, MIPS maintains its own licensing model, allowing design teams to license a MIPS core without committing to a GlobalFoundries fab. Mobileye, for example, is a MIPS customer fabricating at TSMC.</p><p><span class="fr-img-caption fr-fic fr-dii"><span class="fr-img-wrap"><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790370357912-1790370357912.jpeg" width="624" height="351" class="fr-fic fr-dii" /><span class="fr-inner">Atlas Explorer. Source: MIPS</span></span></span></p><h2>Atlas Explorer</h2><p>MIPS supports its portfolio with powerful, accurate modeling tools for pre-silicon validation. <a href="https://mips.com/products/mips-atlas-explorer/"><strong>Atlas Explorer</strong></a> is a Visual Studio Code extension that provides a virtual platform for evaluating MIPS RISC-V IP before fabrication. With it, engineers can profile branch behavior and memory access patterns against a candidate configuration and read ALU utilization and execution flow. And, for parallel development efforts, the platform also lets software teams optimize models on the virtual platform while that silicon is still in development.</p><h2>Powering the Future of Physical AI</h2><p>Intelligence is moving from the data center into the physical world. To deliver optimal designs with minimal risk, chip designers need partners that combine processor IP, software tools, and manufacturing capabilities. By merging, GlobalFoundries and MIPS can now be that solution, giving designers the resources they need to deliver the future of Physical AI.</p>

Does your Physical AI platform have sufficient compute to sense, think, act, and communicate all in real time?

Bringing AI-Native Compute to Mission-Critical, Real-Time Platforms

<p>The first half of 2026 has highlighted a marked shift in the perception of mobile. It is no longer just a smartphone in your pocket, mobile now represents an ecosystem of connected devices that include robots, wearables, extended reality, and vehicles that operate in real-world scenarios.</p><p>Right at the start of the year, we have seen the shape of things to arrive: One of the most visible examples of this shift was NVIDIA’s announcement at CES 2026 of the Isaac GR00T platform for humanoid robots.<sup>[1]</sup> Additionally, companies such as Hyundai and Boston Dynamics demonstrated the updated Atlas humanoid, with plans to deploy it in manufacturing plants by 2028.<sup>[2]</sup> Similarly, LG showcased the CLOiD robot, a seven-axis arm device designed for household chores.<sup>[3]</sup> The trend highlights how AI is pairing digital intelligence with physical action.<sup>[4]</sup></p><h2>Understanding Physical AI and Its Requirements</h2><p>To operate effectively in dynamic environments, these systems rely on physical AI. It generally involves the combination of AI models with sensors and actuators that enable robots or vehicles to act upon real-world environments.<sup>[5]</sup> For instance, in autonomous vehicles, physical AI uses cameras, lidar sensors, and AI mapping to adapt to traffic and weather for navigation.</p><p>For contextual awareness, which includes location, motion, and environmental conditions, AI systems require a continuous stream of sensor data. This contextual awareness must be maintained in real time to ensure safe and predictable behaviour.</p><p>To put this in perspective, a single autonomous mobile robot (AMR) or vehicle can generate upwards of 4 terabytes of data per day when high-resolution cameras, lidar, and telemetry are combined.<sup>[6]</sup> In the absence of reliable connectivity, AI models end up operating on outdated data, which may lead to performance issues and safety risks.</p><h2>Always-On Connectivity Is Not Optional</h2><p>The stakes are significantly higher when AI systems are physical. For instance, in a purely digital setting, a GPT model with outdated data might lead to errors in your article or presentation. In contrast, when AI is controlling a vehicle or robotic arm, lost connectivity can lead to delayed data, equipment damage or production downtime.  </p><p>This is why physical AI systems cannot rely on best-effort connectivity. In real-world deployments, even brief connection losses can compromise situational awareness, delay critical updates, and create blind spots across deployed IoT device fleets. That’s why, always on cellular connectivity essential for continuous monitoring, timely updates, and effective incident response.</p><p>The 2024 autopilot-related incidents involving Tesla serve as a reminder of how delayed sensor fusion can escalate into real-world risks.<sup>[7]</sup></p><p><span class="fr-img-caption fr-fic fr-dii"><span class="fr-img-wrap"><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1782124981740-1782124981740.png" width="602" height="301" class="fr-fic fr-dii" /><span class="fr-inner">Always-on connectivity enables seamless and real-time interaction. Source: Kigen. </span></span></span></p><h2>The Role of Edge AI</h2><p>The industry standard for safe latency is under 10 milliseconds, while a typical cloud round trip could average 60–100 ms.<sup>[8]</sup> Edge AI addresses this gap by processing data locally, enabling immediate response and a more fluid, responsive user experience. </p><p>By keeping sensitive data on the device, edge intelligence also supports privacy by design, while allowing systems to adapt to individual users and environments for greater personalisation.</p><p>For instance, at CES 2026 ARM powered wearables demonstrated real-time health monitoring reducing cloud dependency.<sup>[9]</sup></p><p>That said, the connection to the cloud is still critical. It is just that its role has evolved. For example, if a person steps in front of an industrial robot, the edge AI will stop the robot immediately for the safety of the person. The connected cloud server, on the other hand, will process the incident data across the fleet and train the models to better recognize and avoid similar situations in the future.</p><p>The cloud becomes the layer for fleet level visibility and model training. Critical reactions happen at the edge, while insights learned across deployments continuously improve system performance over time.</p><h2>How eSIM Moves Control to the OEMs</h2><p>With fleets of physical AI devices on the rise, connectivity management becomes more critical than ever. In traditional SIM models, control mostly lies with network operators. IoT devices are often locked to a single carrier or a single region. This is not an ideal situation for OEMs deploying robots or vehicles across multiple countries. </p><p>The eSIM technology changes this dynamic by moving control from network operators to device makers. Earlier, changing a network operator for a fleet of vehicles or robots used to be a time-intensive task, as it involved downtime to physically swap SIMs. With integrated eSIM solutions, OEMs can switch operators with minimal friction.</p><h2>Clearing the Confusion Around eSIM</h2><p>In the industrial space, there is often confusion regarding eSIM. It is not a carrier plan in itself. eSIM, as its name suggests, is a digital yet hardware backed secure SIM (hardware part often is referred to as eUICC) that replaces the traditional removable SIM card with a programmable version. The difference is not what network you use, but how connectivity is managed across devices over their entire lifecycle through the assurance of security. This connectivity is enabled on the device as the eSIM now binds the unique identity of the device with a network, and can be allowed to switch over. The eSIM serves as the trust anchor: it’s primary function being security, and connectivity being secondary. This highlights how eSIMs play their role in autonomous systems that need to be secured from evolving cyber threats. Industrial robots and eSIM enabled devices remain operational for decades so remote programmability is essential to maintain connectivity.</p><p>Over the period of time, change in factors such as network, pricing, and performance may prompt OEMs to switch network operators. eSIM makes this transition easy by allowing users to securely download and activate network operator profiles. This capability also enables IFPP (in-factory profile provisioning) based on the region and requirements.<sup>[10]</sup> OEMs get the option of securely injecting mobile network profiles at the manufacturing stage. They can ship their products to different destinations network settings pre-configured for optimum coverage. As a result, manufacturers can reduce logistical complexity with one global SKU.</p><h2>Achieving Interoperability and Scale</h2><p>Unlike the prior eSIM standard such as M2M (SGP.02) that relies on complex SMS-based triggers, and single network integrations, the latest SGP.32 standard is purpose-built for IoT devices that have more constraints in memory available or may run on low-power networks. It offers eIM (eSIM IoT remote Manager), which allows for zero-touch provisioning of thousands of devices at once. It also supports iFPP (In-Factory Profile Provisioning), enabling profiles to be flashed during manufacturing.</p><p>Since SGP.32 is an open standard, designed with interoperability in mind, from the GSMA, the industry body of all mobile sector players, chipmakers and network providers are all building compatible solutions. This reduces the risk for OEMs of investing in a proprietary technology that might disappear down the line.</p><h2>Conclusion</h2><p>If you’re building physical AI, connectivity cannot be an afterthought. Cellular IoT offers the strongest globalised coverage, inclusive of satellite connectivity, far more suitable to protect IP that resides on the physical AI nodes with assurance of security and network availability. New eSIM standards such as GSMA SGP.32 shift connectivity upstream in the product lifecycle, enabling it to be designed in from the outset rather than bolted on after deployment.</p><p>By defining connectivity strategy early, teams can manage network profiles over the air, select local operators as devices move across regions, and support global deployment without increasing total cost of ownership. For physical AI systems that depend on continuous monitoring, updates, and safety controls, this approach delivers long-term resilience and control. With SGP.32 enabled tooling and in factory profile provisioning, connectivity is aligned with product vision from day one.</p><p>To dive deeper into how OEMs can build resilient, scalable connectivity strategies for physical AI, explore the ABI Research's report, developed in collaboration with Kigen:<a href="https://kigen.com/resources/white-papers/oem-iot-esim-guide/"> https://kigen.com/resources/white-papers/oem-iot-esim-guide/</a></p><hr /><h3>Resources:</h3><ol><li><a href="https://nvidianews.nvidia.com/news/nvidia-isaac-gr00t-n1-open-humanoid-robot-foundation-model-simulation-frameworks" target="_blank" rel="noopener noreferrer"> https://nvidianews.nvidia.com/news/nvidia-isaac-gr00t-n1-open-humanoid-robot-foundation-model-simulation-frameworks</a></li><li><a href="https://www.hyundai.com/worldwide/en/newsroom/detail/boston-dynamics-atlas-named-%2527best-robot%2527-in-best-of-ces%25E2%2584%25A2-2026-awards-by-cnet-group-0000001105" target="_blank" rel="noopener noreferrer">https://www.hyundai.com/worldwide/en/newsroom/detail/boston-dynamics-atlas-named-%2527best-robot%2527-in-best-of-ces%25E2%2584%25A2-2026-awards-by-cnet-group-0000001105</a></li><li><a href="https://www.lg.com/global/newsroom/news/home-appliance-and-air-solution/lg-electronics-presents-lg-cloid-home-robot-to-demonstrate-zero-labor-home-at-ces-2026/" target="_blank" rel="noopener noreferrer">https://www.lg.com/global/newsroom/news/home-appliance-and-air-solution/lg-electronics-presents-lg-cloid-home-robot-to-demonstrate-zero-labor-home-at-ces-2026/</a></li><li><a href="https://www.forbes.com/sites/ronschmelzer/2026/01/10/physical-ai-made-waves-at-ces-2026-what-is-it/" target="_blank" rel="noopener noreferrer">https://www.forbes.com/sites/ronschmelzer/2026/01/10/physical-ai-made-waves-at-ces-2026-what-is-it/</a></li><li><a href="https://www.ibm.com/think/topics/physical-ai" target="_blank" rel="noopener noreferrer"> https://www.ibm.com/think/topics/physical-ai</a></li><li><a href="https://medium.com/@autodriveai/autonomous-cars-will-collect-approximately-4-tb-of-data-every-hour-of-driving-3819aba33204" target="_blank" rel="noopener noreferrer">https://medium.com/@autodriveai/autonomous-cars-will-collect-approximately-4-tb-of-data-every-hour-of-driving-3819aba33204</a></li><li><a href="https://www.usatoday.com/story/money/legal/2025/06/24/tesla-lawsuit-autopilot-crash/84336338007/" target="_blank" rel="noopener noreferrer">https://www.usatoday.com/story/money/legal/2025/06/24/tesla-lawsuit-autopilot-crash/84336338007/</a></li><li><a href="https://www.omnitron-systems.com/blog/understanding-network-latency-and-its-impact-on-industrial-applications" target="_blank" rel="noopener noreferrer">https://www.omnitron-systems.com/blog/understanding-network-latency-and-its-impact-on-industrial-applications</a></li><li> <a href="https://www.arm.com/markets/consumer-technologies/wearables" target="_blank" rel="noopener noreferrer">https://www.arm.com/markets/consumer-technologies/wearables</a></li><li><a href="https://kigen.com/resources/white-papers/ifpp/" target="_blank" rel="noopener noreferrer">https://kigen.com/resources/white-papers/ifpp/</a></li></ol><h2 id="isPasted"><br /></h2>

Physical AI

Latest Posts

Building the Feedback Loop for Physical AI

The Software-First Shift

Bringing AI-Native Compute to Mission-Critical, Real-Time Platforms

How Physical AI Is Redefining Mobile and Why eSIM Matters