Cover: a conceptual illustration of the architecture, with a processor, FPGA and industrial sensors.
On 10 November 2026, Lattice announced the Lattice NXP PCIe Companion solution, developed with NXP: an NXP i.MX 95 processor paired with a CertusPro-NX or Certus-NX FPGA, connected over PCIe. The stated goal is to combine application processing, programmable I/O and timed operations for industrial automation, robotics and edge systems. Details are available in the official Lattice announcement.
For teams developing a machine or measurement instrument, the practical question is: when does it make sense to add an FPGA alongside embedded Linux? The answer starts with the signals to acquire, the deadlines to meet and the path each data item takes to the application.
When an FPGA makes sense alongside Linux
The Lattice reference design page proposes dividing the work between the two devices: sensor aggregation, custom interfaces and selected real-time processing tasks go to the programmable logic; higher-level applications run on the processor. This separation supports a dedicated hardware pipeline while retaining the Linux software ecosystem.
When evaluating a design, an FPGA becomes useful for parallel inputs, tightly timed signal sequences or protocols that the available peripherals cannot handle. Linux can manage configuration, the operator interface, storage, networking and result analysis. If the SoC peripherals or a microcontroller already meet the requirements, the additional development and verification costs of programmable logic need a clear justification.
The NXP reference: data, registers and notifications
The technical article i.MX95 PCIe connection with FPGA describes a PCIe x1 connection: the i.MX 95 acts as the Root Complex and the FPGA as the endpoint. The Linux driver lattice_nxp_pcie_ep.c provides three paths:
- Data: coherent DMA buffers in host memory, accessed by the FPGA through PCIe transactions.
- Control: MMIO access to the BAR1 window for registers and memory exposed by the endpoint.
- Completion: MSI interrupts and wait commands to notify software when an operation completes.
The application uses a character device and IOCTL commands. The driver supplies transport and control primitives; the application protocol must be defined for the product.
Acquisition: synchronizing sensors before transferring data
Consider an inspection machine with analog sensors, encoders and digital inputs as a design example. The FPGA could distribute triggers, collect samples from converters, attach timestamps and sequence numbers, and accumulate blocks in FIFOs. Any filtering or feature extraction would need to be sized against the required resources, precision and sample rates.
A shared timestamp does not automatically make measurements simultaneous. Clocks, interface delays and the actual ADC conversion instants must be checked. Clock domain crossings also require dedicated design work. These issues belong upstream of the Linux connection: a transfer preserves a timing relationship only if that relationship was captured correctly.
The block format should make channels, protocol version, missing sequences and overflows observable. The design must also specify what happens when the consumer slows down: pause acquisition, discard data according to an explicit rule, or stop the machine cycle.
DMA and MSI: moving blocks and waking software
DMA allows a device to transfer data into memory without asking the CPU to copy every individual sample. The driver must use DMA addresses obtained through the kernel APIs: a process pointer is not an address to hand to the FPGA. The Linux kernel DMA guide also distinguishes coherence from ordering: even coherent memory may require barriers so that descriptors and commands become visible in the intended order. The path to the application may still involve additional copies.
MSIs are interrupts signaled through memory writes. An acquisition pipeline can issue one notification per completed block, reducing interrupt frequency compared with notifying on every sample. Receiving an interrupt and completing the application processing remain separate events.
FPGA timing and latency across the complete chain
For an inspection system, the relevant time runs from the physical event to a decision the machine can use. An initial timing budget can be expressed as:
T_total = T_acquisition + T_batching + T_transfer + T_driver/scheduling + T_processing + T_output
A verified hardware sequence in the FPGA can meet its own clock constraints; the rest of the path adds waiting, contention and software work. PREEMPT_RT reduces several sources of kernel latency through increased preemptibility, priority management and threaded interrupt handling. The product timing budget still needs measurement on the actual configuration, under representative CPU load, network traffic and I/O.
If an output must meet a very tight deadline, it may be appropriate to close that path directly in the programmable logic. Linux would then receive results and diagnostics. The choice depends on the maximum permitted delay, algorithm complexity and expected error conditions.
A numerical example for the inspection machine
Assume 8 channels at 100 ksample/s, with 16-bit samples. The sample payload alone is 8 × 100,000 × 2 = 1,600,000 bytes/s, or 1.6 MB/s in decimal units, before timestamps, headers and overhead. These are sizing assumptions for this example, not measured performance figures for the NXP–Lattice solution.
A 10 ms block contains 16,000 bytes of samples. If it is delivered only when complete, the first sample waits almost 10 ms for batching alone. Reducing the block to 1 ms lowers that delay and gives 1,600 bytes of payload per block, while increasing the delivery frequency.
To absorb a 50 ms consumer stall, an initial useful-capacity estimate is B ≥ R × T = 80,000 bytes, with metadata, margin and data already in flight added on top. Buffering absorbs temporary slowdowns; continuous acquisition requires average consumption to keep pace with production.
Updating the bitstream in an industrial product
In the NXP reference, updating the bitstream over PCIe is the demonstration application built on the driver primitives. The documentation also addresses connection handling after reconfiguration, PCIe removal and rescan. The driver does not interpret the bitstream format.
To turn this mechanism into a product feature, we propose defining image authentication, compatibility between board, logic and driver, a controlled acquisition stop, and a recovery procedure together. Testing should include incompatible images, power interruptions and failure of the endpoint to return. Sending a file covers only part of the update lifecycle.
From reference design to a system that can be verified
A useful prototype should demonstrate the complete path: a known stimulus at the inputs, numbered and verifiable blocks in RAM, measured timing through to the application, and defined behavior on overflow or reset. The Linux BSP, driver, FPGA logic and application software should be versioned and tested as parts of the same system.
At Silicon LogiX, we can support your team with FPGA and digital logic development and embedded Linux integration, connecting acquisition, drivers and applications. For an inspection machine or measurement platform, the starting point is concrete: signals to acquire, sample rates, deadlines and acceptance tests.
Canonical source: Linux and FPGA over PCIe: NXP–Lattice for sensors and industrial automation.
