Suchit Lepcha: The Only Microprocessor in NVIDIA’s AI Sensor Ecosystem

NVIDIA’s Holoscan Sensor Bridge (HSB) connects high-bandwidth sensors to GPU-accelerated AI pipelines over Ethernet. The ecosystem partners building sensor bridge solutions include Altera, Lattice Semiconductor, Microchip Technology, and STMicroelectronics. All of them provide FPGA-based or microcontroller-based designs. NXP Semiconductors is the only microprocessor partner on that list.

The difference is DPDK (Data Plane Development Kit). Where every other partner uses dedicated silicon to meet the latency requirements of real-time sensor streaming, NXP runs a general-purpose applications processor on Linux. DPDK’s user-space packet path is what makes that viable.

Suchit Lepcha manages the System Engineering team at NXP India, with Hemant Agrawal serving as the Technical Director. The team has been working with DPDK since before NXP became a founding member of the project. The engagement that put NXP on the Holoscan Sensor Bridge partner page started with an industrial robotics customer.

The 200-microsecond proof point

The customer needed to deliver 4K camera sensor data to a central AI inference engine within 20 milliseconds end-to-end. The sensor capture alone consumed 15.6 of those milliseconds. Linux had been written off. The kernel networking path added too much overhead, and the margin between capture time and delivery deadline was measured in fractions of a millisecond. The assumption was that only an FPGA could close the gap.

Suchit’s team ran the solution on NXP’s i.MX 95 applications processor, a part designed for edge AI and vision workloads, not traditional networking. The i.MX 95 features six Arm Cortex-A55 cores, integrated 10-gigabit Ethernet with Time-Sensitive Networking (TSN), an NXP eIQ Neutron NPU for on-device inference, and an image signal processor handling up to eight camera sensors. By using DPDK to bypass the kernel and deliver packets directly in user space, the team achieved 16.5 milliseconds end-to-end. DPDK’s contribution to the transmission path sat in the 200 to 300 microsecond range on top of the sensor capture time. The team also developed additional optimizations that NXP has filed a patent application for.

The result is specific. An applications processor running Linux beat the latency threshold that was assumed to require an FPGA. That is what earned NXP its place in an ecosystem otherwise built entirely on dedicated silicon.

From proprietary stack to upstream DPDK contributor

The robotics engagement did not come out of nowhere. NXP’s relationship with DPDK traces back to a decision that reshaped how the company approached user-space networking.

Before committing to DPDK, NXP maintained its own proprietary user-space networking stack called USDPAA (User Space Datapath Acceleration Architecture). USDPAA worked but locked customers into NXP silicon. When a major customer demanded the ability to port their networking application across processor architectures without rewriting their stack, the calculus changed. Portability required a common framework. DPDK was that framework.

NXP became a founding member of the DPDK project at the Linux Foundation and began upstreaming its platform support. Today, Hemant Agrawal serves on the DPDK Technical Board, and NXP engineers maintain the ENETC and ENETFEC poll-mode drivers (PMDs) that support the NXP Layerscape and i.MX processor platforms.

The Cyber Resilience Act as a forcing function for upstream contribution

Suchit sees the European Union’s Cyber Resilience Act (CRA) as an accelerant for upstream contribution discipline. The CRA requires vendors to demonstrate ongoing security maintenance for software components shipped in commercial products. For NXP’s customers building products with multi-year lifecycles in industrial and automotive environments, the provenance and maintainability of every software component matters.

Fully upstream DPDK code, maintained by the community with transparent patch review and release processes, satisfies CRA requirements in a way that forked or proprietary stacks cannot. Customers are now explicitly asking for upstream DPDK support as a procurement condition.

Where DPDK goes next on embedded silicon

The pattern Suchit describes extends beyond one customer win. Sensors of all types, including cameras, lidar, radar, and inertial measurement units (IMUs), are consolidating onto Ethernet as a transport layer. AI inference engines at the edge need that sensor data delivered with deterministic low latency. The Linux kernel networking stack was not built for this workload. DPDK was.

For a project that started in telecommunications infrastructure, showing up as the only software-based solution in an FPGA-dominated sensor ecosystem is not a benchmark result. It is a statement about where the project is headed.

Frequently Asked Questions

Get Involved: Review your first DPDK patch

Last Updated: 07/14/2026