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

Physical AI is one of the fastest-moving fields in engineering today, and it presents significant design challenges for engineers. 

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.

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, MIPS goes beyond licensing processor IP alone—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.

Silicon Challenges for Physical AI

Timing Constraints

When designing Physical AI systems, 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. 

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.

Power and Thermals

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.

Certification and Longevity Requirements

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. 

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.

Mixed Workloads

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.

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.

In that context, optimizing a core for one workload can compromise the requirements of the other.

From IP Vendor to Foundry

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.

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.

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.

Platform-Level Silicon Partners

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.

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.

Providing an Extensive Processor IP Portfolio

When selecting a supplier, another factor to consider is their ISA.

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.

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. 

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.

Pre-Silicon Workload Modeling

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. 

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. 

The Case for GlobalFoundries

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.

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.

The MIPS Atlas RISC-V Portfolio

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).

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.

• Sense 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.

• Think 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.

• Act covers real-time control of motors, actuators, and batteries, where embedded processors must execute control loops deterministically and often meet functional-safety requirements.

• Communicate 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.

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, MIPS expects a customer automotive platform based on the M8500 to enter production in 2027.

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.

Atlas Explorer

MIPS supports its portfolio with powerful, accurate modeling tools for pre-silicon validation. Atlas Explorer 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.

Powering the Future of Physical AI

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.