Shorter data path
On supported platforms, external data is written straight into GPU memory, cutting out the host-memory relay.
PHYSICAL AI · High-speed data interface
Move physical-world data straight into compute.
On one side of the door is the physical world; on the other, GPU compute. This line is the door itself — bringing heterogeneous, high-rate, tightly time-correlated sensing data into the GPU in a unified, synchronisable and observable way, ready for the algorithm to use directly.
The problem: without a data path, compute is just a number
AI-RAN and robotics perception look like two industries, but they run into the same bottleneck.
- Shared requirement: large volumes of heterogeneous, time-correlated data must enter the GPU continuously and be used by algorithms in time
- Today's approach: interfaces, drivers and synchronisation are developed separately — every new data source means starting over
- Relay overhead: part of the data still passes through the CPU and host memory, adding memory traffic and scheduling jitter
- Integration cost: per-device development makes system integration slow and poorly reusable, so work never settles into a standard product
Two families of data to bring in
They differ in interface, rate and timing — and that is exactly what makes this hard.
| Source | Typical data | Why it is difficult |
|---|---|---|
| Radio side | Raw IQ samples, wireless fronthaul data, radar returns | High rate and continuous, with strict requirements on time alignment and zero loss; multi-antenna scenarios add coherence problems |
| Robotics side | Images, point clouds, six-axis force, motion state | Sample rates and latency magnitudes differ enormously between modalities; high-rate raw data and low-rate state data must be ingested to suit their own characteristics |
Four improvements we target
Each one is something a customer can verify, not a concept.
More usable data
Unified timestamps, stream identifiers and buffer management support multi-source alignment, record-and-replay and anomaly tracing.
Lower integration cost
A standard SDK and protocol plug-ins let upper-layer algorithms reuse one data interface instead of being rewritten per device.
Higher AI adoption
High-speed SerDes interfaces raise the proportion of radio and robotics systems that can connect to an AI platform.
Architecture direction
Four segments on one path, from physical interface to GPU algorithm.
-
STEP 01
Multi-source ingress
Front ends support high-speed Ethernet, JESD204B/C, Aurora and custom serial interfaces in stages, covering many physical-layer forms across radio and sensing.
-
STEP 02
FPGA real-time processing
Protocol parsing, hardware timestamping, necessary signal pre-processing, buffering and traffic scheduling happen on the FPGA side.
-
STEP 03
Direct to GPU
Data is written into GPU memory over PCIe peer-to-peer DMA and a suitable GPU Direct RDMA path.
-
STEP 04
Unified runtime
CUDA programs handle baseband processing, sensing fusion and AI inference, while the CPU handles configuration, resource management and fault recovery — with its overhead steadily reduced.
Two connection forms
Chosen by distance and deployment conditions, not one design for everything.
In-chassis direct attach
When the ingress module and FPGA sit in the same chassis, they connect over PCIe. The shortest path and the most controllable latency, for scenarios with the tightest timing requirements.
- Shortest data path
- Most controllable latency and timing
- Suited to fixed, centralised deployment
Long-distance SerDes
For deployments that need physical separation, we develop low-power SerDes links where the engineering is about the link itself, not just the protocol.
- Low-power serial links
- Engineering validation across distance and installation conditions
- Groundwork for multi-node and distributed deployment
Vision: mobile entities and fixed infrastructure on one architecture
What this line ultimately unifies are two things that appear to have nothing in common.
- The 6G base station on the wall — fixed infrastructure
- The embodied robot moving on the ground — a mobile entity
- Both share the same requirement for high-speed data access: physical-world data must reach compute continuously
- Turning that shared requirement into a standard product serves both ends at once, instead of being rebuilt for every industry
Frequently asked questions
What stage is this line at?
Research and planning; there is no deliverable standard product yet. We publish it under "technology direction" rather than "product" precisely so partners know this — and that is also why it is worth talking now: joining at the direction stage carries the lowest cost of change.
How is this different from existing sensor-ingest approaches?
Existing approaches mostly focus on the path where sensors reach the GPU over a network. Ethernet encapsulation, transport and NIC processing add cost, and they do not address multi-antenna coherence or the far stricter synchronisation demands of the 6G era. Our direction is to shorten that path itself and to treat sample synchronisation, spatio-temporal semantics and data integrity management as the core problems.
Can we work together now, and in what form?
Yes. We are looking primarily for partners with concrete metric requirements and test scenarios, and we work through joint development, paid validation or design-in — proving things under real operating conditions rather than through datasheets.
Will you publish performance figures?
Once there is measured evidence, yes. We don't want to trade an unverified number for short-term attention — at our stage, promising something we can't deliver costs far more than staying quiet a while longer.
If your system is stuck at the data path too
Describe the interface forms, data rates and timing requirements, and we can tell you whether this is doable and where the cheapest way in is.