Linux Kernel Bypass
Linux Kernel Bypass With MLE NPAP Increased Ethernet speeds push a need to offload CPUs from the burden of TCP/UDP/IPv4 processing. Various kernel bypass options exist, some include so-called RDMA (Remote DMA). NPAP can provide architecture choices for implementing such kernel bypasses. Normally, from a CPU’s perspective, TCP socket I/O means sending and/or receiving (raw) network data between the host CPU and the NIC. The kernel runs network protocol processing for IPv4, TCP, and socket APIs. User space applications that generate and/or digest the network data add to the CPU processing burden. RDMA skips most steps and a so-called rNIC (RDMA NIC) device driver directly interfaces with user space memory, effectively bypassing the kernel: MLE NPAP can operate in a similar way, where NPAP does all TCP/IPv4 processing in dedicated ASIC / FPGA logic and then a (Linux) device driver copies the payload data between user space memory and MLE NPAP. Next: Implementing Time-Sensitive Networking (TSN)Time-Sensitive Networking (TSN)
Implementing Time-Sensitive Networking (TSN) TSN has become a set of emerging, open IEEE standards with momentum in industrial markets (for 10/100/1000 Mbps speed) and in next-generation Automotive Zone architectures (for 10/25/50 Gbps speeds). Aspects such as Traffic Shaping also find application in telecommunication, Provider Back-Bone (PBB) Switching or Software-Define Wide Area Networks (SD-WAN), for example. TSN and TCP can be combined according to the OSI Layers. The outcome is a deterministic and reliable network protocol, which makes TCP/IPv4 over TSN a very good candidate for all networking where IT (Information Technology) and OT (Operations Technology) converge, or in Systems-of-Systems backbones. TSN itself is quickly evolving so please contact us for more information! Contact Us Next: MLE NPAP with Transport Layer Security (TLS)Transport Layer Security (TLS)
MLE NPAP with Transport Layer Security (TLS) MLE has been working with partner Xiphera to integrate MLE NPAP with Xiphera’s TLS IP Cores for FPGA. Successful integration has been delivered to first customers. TLS is a cryptographic protocol that provides end-to-end data security, on top of the Transmission Control Protocol (TCP) layer. Implementing TLS has become a standard practice for building secure web apps. With growing needs for security compliance, for example under IEC 62443, TLS is also an option for protecting sensitive data transported using MLE NPAP. Collaboration within the FPGA ecosystem created joint solutions combining MLE’s TCP/IPv4 Network Protocol Accelerator Platform (NPAP) with Xiphera’s TLS 1.3 to ensure secure and reliable connection between devices over LAN and WAN. Since the TCP/IPv4 stack and the TLS 1.3 security protocol – including importantly both key exchange and key management – are both executed entirely in hardware, the joint solution has both scalable high-speed performance and minimizes attack surface, especially when compared to a software-based approach. The FPGA hereby utilizes the hardware Root of Trust, best suited for applications like critical communication in defense, space technology, and energy production and distribution.FPGA Design Integration
FPGA Design Integration of MLE NPAP
MLE NPAP is available as VHDL RTL source code or as a netlist suitable for synthesis by 3rd party and FPGA vendor tools which makes it possible to support almost any FPGA or ASIC target platform. The following toolchain versions have been tested at MLE:
| Version | AMD/Xilinx | Altera/Intel | Lattice Semi | Microchip |
|---|---|---|---|---|
| NPAP 2.5.0 (or newer) | Vivado 2022.2 Vivado 2024.2 | Quartus Prime Pro 22.4, 24.2 | Radiant 2024.2 | Libero 2024.2 |
| NPAP 2.4.5 (latest) | Vivado 2022.2 | Quartus Prime Standard 22.4 | n/a | n/a |
| NPAP 1.10.1 | Vivado 2018.3 | Quartus Prime Pro 22.1 | n/a | Libero 2021.2 |
Starting with version 2.5.0, NPAP is delivered as VHDL IEEE-1076 2008 RTL source code. This standard is fully supported by almost all modern FPGA toolchains, including those listed in the table above.
However, some older toolchains, such as Altera Quartus Prime Standard (required for legacy devices like Stratix V), do not offer full VHDL-2008 support. For these specific tools, the latest compatible release is NPAP v2.4.5.
MLE NPAP is Optimized for FPGA Pipelining
Starting with NPAP 2.0, RTL code has been optimized for FPGA pipelining such as Altera/Intel Hyperflex, Altera/Intel HyperFlex2 or AMD/Xilinx IMux. This avoids so-called “FPGA bloat”: Unlike other FPGA IP Cores which rely on 256 or even 512 bit wide datapaths, NPAP comes with more shallow combinatorial circuits to increase the FPGA clock speed, and thereby the on-chip throughput.
For more information please refer to MLE Technical Brief TB20230523.
Synchronous vs. Asynchronous Clocking of the Ethernet MAC
FPGA Resource Estimates
MLE NPAP Resource Estimates for FPGA
Resource estimates are directly tied to the specific set of compile-time parameters: Therefore, a typical FPGA implementation which integrates MLE NPAP can range from as low as 10K LUTs to 1 million LUTs (for dozens of TCP cores).
MLE NPAP for AMD Versal AI Edge
The following table shows resources for AMD/Xilinx Versal AI Edge Series fabric (xcve2302-sfva784-1LP-e-S-es1) compiled with AMD/Xilinx Vivado/Vitis 2024.1 – instantiating the following design features:
- Ethernet block
- IPv4 block
- 1 UDP block
- 4 instances of TCP blocks
- Diagnostics blocks
MLE NPAP for AMD/Xilinx Ultrascale+ Series
The following table shows resources for AMD/Xilinx Zynq Ultrascale+ MPSoC ZU9EG compiled with AMD/Xilinx Vivado 2022.2 – instantiating the following design features:
- 10 GigE Low-Latency MAC from Fraunhofer HHI
- Ethernet block
- IPv4 block
- UDP block
- 10 instances of TCP blocks (2 used for netperf)
- TCP and UDP Diagnostics blocks
- 10 GigE Low-Latency MAC from Fraunhofer HHI
- Ethernet block
- IPv4 block
- UDP block
- 10 instances of TCP
RTL Simulation and Verification
RTL Simulation and Verification
MLE ensures the highest quality and reliability for every NPAP release through a rigorous, multi-layered validation strategy built on a robust Continuous Integration (CI) framework. This automated process validates NPAP from initial simulation through final hardware deployment.
Our Quality Assurance process is documented in the MLE Quality Manual (QAM001 Rev. 13a) and involves:
- Extensive Simulation-Based Verification: We conduct comprehensive RTL simulations (testing NPAP-to-NPAP) as well as advanced, system-level co-simulations (testing NPAP-to-software). This automated test suite validates all aspects of protocol behavior, from register access and TCP connection management to complex corner-case scenarios like retransmissions, backpressure, and priority handling.
- Rigorous Hardware Validation: Simulation is followed by automated nightly hardware regression testing on a large, physical test farm. We validate NPAP across a wide array of target platforms from all major FPGA vendors, including AMD, Intel, Lattice, and Microchip.
- Real-World Interoperability Testing: Hardware tests cover numerous real-world use cases, including board-to-board latency and performance benchmarks, and board-to-PC interoperability against standard Linux/Windows stacks using tools like Netperf. We also perform stress tests under adverse link conditions using the integrated Network Impairment Generator (see Section 3.5).
This comprehensive approach guarantees that NPAP delivers deterministic, high-performance, and reliable operation across all supported target technologies.
Extensive RTL simulation suite
Network Administration
MLE NPAP Network Administration Managing a network infrastructure commonly involves setting IPv4 addresses, managing TCP sessions, and inspecting hardware statistics. In a standard Linux environment, these tasks are typically performed using command-line tools that interact with the software-based network stack and NIC hardware. With MLE NPAP, similar configurations are possible in two distinct ways. You can parameterize MLE NPAP using a wide range of compile-time parameters in HDL. Or, you can use run-time parameterization via MLE NPAP’s Python-based software which comprises the NPAP Hardware Abstraction Layer (HAL) python package and the command-line tool (npap-admin). This software interfaces is used in almost all Evaluation Reference Designs (ERD) which cover all options such adminstration via UART, I2C or PCIe, making it easy to adopt MLE NPAP to your use case (see MLE NPAP Control-Flow View and Hardware Abstraction Layer). NPAP HAL utilizes the NPAP ERD’s AXI4-lite register interface to provide a wide range of runtime parameterizations. These include network administration tasks such as setting the IPv4 or MAC address and configuring TCP/UDP sessions, as well as testing and diagnostic functions such as setting up throughput tests with the data generator checker or the Netperf IP core or managing the kernel’s diagnostic blocks. In an NPAP ERD (and most likely within your design as well)Changelog
MLE NPAP Changelog Table of Contents MLE NPAP ChangelogMLE NPAP Version 2 DevelopmentMLE NPAP Version 1 Development The following lists MLE’s engineering changelog for MLE NPAP. With the release of NPAP v2.2.0 the development cycle has changed from 1.x to 2.x. Version 2.4.5 uses the least amount of resources and includes no diagnostics.Version 2.5.0 and onwards requires VHDL-2008. VHDL-2008 is not fully supported in Quartus Prime Standard, for example. Please inquire with any questions regarding tool support. MLE NPAP Version 2 Development 20260630 No DIag (and no VHDL-2008) TB2026xxxx Latency / RTO Hybrid TC 20260228 NPAP Kernel v2.9.0 TCP #6668 – rework handling of RTO settings #7734 – add simulation timeout to TCP transmit module to shorten establish time in simulation ERD v3.4.11 all bump ERD to v3.4.11 #6525 – fix naming by using different names for same signals #6668 – update RTO signals naming between TDA and TCA #7804 – fix psh signal connection between TDA and TCA IP update to NPAP v2.9.0 update to TDA v5.0.0 update to TCA v5.0.0 20260131 NPAP Kernel v2.8.1 GENERAL #7630 – add support for Quartus Prime Standard Edition TCP #7516 – fix data segment handling if TCP receiver is turned off #7722 – fix TcpCmdStopRecv command does not disable TCP receiver #7723 – improveProtocol Support (RFC1122)
MLE NPAP Protocol Support (RFC1122 excerpt)
MLE NPAP Ethernet Layer
| Feature | Section | Must | Must Not | Implemented |
| Send Trailers by default without negotiation | 2.3.1 | x | x | |
| ARP | 2.3.2 | |||
| Flush out-of-date ARP cache entries | 2.3.2.1 | x | (x) | |
| Prevent ARP floods | 2.3.2.1 | x | (x) | |
| Ethernet and IEEE 802 Encapsulation | 2.3.3 | |||
| Host able to: | 2.3.3 | |||
| Send & receive RFC-894 encapsulation | 2.3.3 | x | x | |
| Send K1=6 encapsulation | 2.3.3 | x | ||
| Use ARP on Ethernet and IEEE 802 nets | 2.3.3 | x | x | |
| Link layer report b’casts to IPv4 layer | 2.4 | x | ||
| IPv4 layer pass TOS to link layer | 2.4 | x | ||
| No ARP cache entry treated as Dest. Unreach. |
2.4 | x | x |