The Software-First Shift

Software Is Driving The Conversation

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.

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.

The design question becomes: Which combination of general-purpose compute, specialized acceleration, memory, interfaces, and software best satisfies this workload’s measured requirements?

What Happens Beneath The Code Matters

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.  

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.

• Where performance bottlenecks occur

• How workloads map to hardware

• Which functions can benefit from specialized acceleration

• How software decisions affect power and latency

• Where hardware changes could deliver meaningful gains

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.

From Software Running On Hardware To Software Shaping Hardware

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. 

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.

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. 

Open Architectures Change Who Gets To Participate

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.

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.

Why This Matters For Physical AI

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. 

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. 

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: Acies for inference-native AI, Actus for event-native real-time control, and Aegis for safety-native application processing. Each gives developers an earlier environment for software bring-up, workload testing, performance analysis, and ecosystem development.

The Developer Becomes Part Of The Hardware Conversation

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. 

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.

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. 

Software-To-Silicon Becomes The New Design Loop

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.

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.

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.

Conclusion

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.