Athos Silicon has started the next phase of development for its ‘multiple system on chip’ (mSoC) controller in a Level 4 autonomous test vehicle.

The vehicle is equipped with a complete set of Lidar, radar and camera systems, enabling live testing and integration in real-world autonomous driving.

The vehicle will serve as a dedicated platform for prototyping, benchmarking and system integration using the mSoC architecture. It also enables collaboration with partners bringing full autonomy software stacks onto silicon.

“Testing with real-world sensor loads is where it counts. This vehicle provides us with the platform to bring up mSoC under true Level 4 conditions, with the bandwidth, compute and safety-critical constraints that actually define full autonomy. This is a major step forward for mSoC,” said Charnjiv Bangar, CEO and co-founder of Athos Silicon.

The mSoC is a fundamentally redesigned architecture for safe, high-performance, chiplet-based autonomous designs in automotive and avionics applications. The architecture, designed for functional safety, anticipates and isolates hardware faults, rerouting around them in real time with no single point of failure.

Distributed scheduling with built-in voting logic ensures that safety at the hardware level meets ASIL-D and DO-254 standards. The architecture is fully modular, allowing new features such as AI, sensor fusion or general-purpose compute chiplets to be added without redesigning the system. This will be tested out in the vehicle.

A key part of the mSoC hardware is the ability to use a directed acyclic graph (DAG) for deterministic loops for safety-critical software.

Most robot operating systems or middleware systems use a DAG to ensure predictable data and control flow. A DAG ensures that there are no cyclic dependencies, which is essential for deterministic scheduling and deadlock avoidance.

DAGs can be used to represent task dependencies or instruction scheduling in computer architecture, and Athos is using graph theory and the concept of reservation tables to maintain dependencies and determinism within the architecture, said Francois Piednoel de Normandie, CTO, who is a former architect of ADAS hardware at Mercedes.

A reservation table is a key structure in out-of-order (OoO) execution engines, enabling instructions to be issued and executed as soon as their operands are ready, rather than strictly in program order. Each entry in the reservation table corresponds to a functional unit such as the arithmetic logic unit and temporarily holds instructions waiting to be executed.

When an instruction is decoded, it is placed into the reservation table along with metadata such as operand availability and destination register. If an operand is not yet available (e.g., waiting on a previous instruction), the reservation station tracks the tag of the producing instruction.

When all operands are ready and the corresponding functional unit is free, the instruction can be issued for execution. This mechanism allows for non-blocking execution, exploiting instruction-level parallelism and maximising throughput by avoiding stalls due to data hazards. Additionally, it enables dynamic scheduling, where the actual execution order can differ from the program order without violating correctness. This flexibility is central to the performance advantages of OoO cores, particularly in complex workloads with many interdependent instructions and irregular data patterns.

However, this can be a challenge for safety-critical systems.

Deterministic loops are those whose behavioural output, timing and state transitions are completely predictable and repeatable for a given input. This predictability means that the loop always executes the same number of iterations and accesses memory or hardware resources in a known, structured way. Determinism is critical in systems requiring reliability, safety and verification, such as in real-time embedded systems, functional safety and high-assurance computing.