Bring up a Kalray Coolidge V1

Where this stands

SpaceOS does not run on a Kalray Coolidge V1 today. No target profile ships for it, and the platform source lists the board under “Not currently supported” in its support matrix (docs/support-matrix.md).

The board was demonstrated under the OSIP T1 programme at the minimal integration level. That is programme history, and the code does not carry it: Kalray, Coolidge, MPPA, AccessCore and OpenCL appear nowhere in the platform source, and none of the five shipped target profiles declares an accelerator.

The vendor host preparation below is Kalray’s and it works. The SpaceOS half does not exist, so this page stops where the MPPA is visible to the host.

The Kalray Coolidge V1 is an 80-core processor built for high-throughput edge AI and signal processing workloads. Kalray calls the architecture MPPA, for Massively Parallel Processor Array. It is intended as a daemon install in the target matrix, on an x86_64 host with the MPPA accelerator attached.

Custom carrier integration and radiation-tolerant deployment paths follow the same firmware-and-host flow with vendor-specific board support package overlays.

Use AccessCore 5.x, Kalray’s software development kit. Validate any later SDK release against your host integration before you rely on it.

Hardware topology

• 80 processing cores (5 clusters of 16, plus management cores) running at up to 1.2 GHz. Each is a very long instruction word (VLIW) core, which issues several operations per cycle from one wide instruction.
• DDR4 main memory and multiple PCIe Gen 4 host links, with optional 100 Gbps Ethernet.
• Two integration patterns:
  • PCIe card. The Coolidge V1 attaches to an x86_64 host over PCIe. The host runs Linux, and the MPPA acts as an accelerator the host runtime reaches.
  • Standalone. The Coolidge V1 runs its own real-time operating system and is addressed directly. This pattern is less common in SpaceOS deployments.

SpaceOS intends the PCIe-accelerator pattern, where a unikernel or container in a partition would call the MPPA over the hardware acceleration delegation path. That is design. The accelerator schema models Gpu and Fpga kinds and carries signed grants; it has no MPPA kind, and no shipped profile declares an accelerator.

Install the AccessCore SDK

Follow Kalray’s AccessCore installation documentation for the host. SpaceOS expects the MPPA runtime and kernel modules to be installed and visible to the host before you deploy a workload.

Install and verify the host components:

1. Install the AccessCore runtime and tools on the x86_64 host (Debian / Ubuntu packages from Kalray).
2. Verify the MPPA device shows under PCIe (lspci | grep -i kalray).
3. Load the MPPA kernel modules.
4. Confirm the host has KVM, which is what a Solo5 hvt substrate would need. The substrate would isolate the service; the MPPA would be the accelerator that service reaches through a broker.

There is no step 5. SpaceOS publishes no runtime package for this host and no target profile to bind it to, so the install and connect steps that would follow do not exist today.

Verify the substrate

ls /dev/kvm                       # KVM enabled on the host
lspci | grep -i kalray            # MPPA visible
ls /dev/mppa*                     # MPPA kernel-module devices
kvx-accesscore-utils --version    # AccessCore tooling

Selection criteria

Choose the Coolidge V1 when:

• Your workload is signal-processing-heavy and gains from many-core parallelism: radar and synthetic-aperture radar (SAR) processing, beamforming, encrypted-link processing, and dense linear algebra.
• You can integrate a PCIe accelerator on the bus.
• Your mission has the power envelope for an x86_64 host plus an MPPA card.

For AI inference on TensorRT or Vitis AI, see the Jetson TX2i or the VCK190. All three are in development; the Raspberry Pi CM5 is the supported board to prove a workload on today.

Operating notes

The intended dispatch to the MPPA is through the AccessCore native API or OpenCL. No such dispatch exists in the platform source today. The runner’s accelerator broker adapts a signed grant onto an external broker and defines no accelerator interface of its own.