4.8. Latency Analysis Results
4.8. Latency Analysis Results MLE analyzed processing latency using RTL simulation of two instances of NPAP (using different clock speeds) connected via 10G LL MAC via XGMII (clocked at 156.25 MHz). TCP Payload Size [Byte]Clock cyclesLatency [ns] at 175 MHzLatency [ns] at 322 MHzLatency [ns] at 550 MHz162354.3192.5112.73267382.9208.1121.86473417.1226.7132.716091520.0282.6165.5448145828.6450.3263.69602411,377.1748.4438.212162891,651.4897.5525.514563341,908.61,037.3607.3 Latency was measured “one-way, door-to-door”: Using RTL simulation we count the number of clock cycles it takes from sending payload data from one NPAP instance (TX) via the full NPAP kernel until the other instance of NPAP receives that payload data (RX). Here the system-level block diagram: Obviously, increasing the NPAP clock frequency will reduce latency for asynchronous NPAP subsystems. More information on dependable latency numbers can be found in our Technical Brief “Myth-Busting Latency Numbers for TCP Offload Engines.” Myth-Busting Latency Numbers for TCP Offload Engines 🌐 www.missinglinkelectronics.com MLE (Missing Link Electronics) is offering technologies and solutions for Domain-Specific Architectures, which focus on heterogeneous computing using FPGAs. MLE is headquartered in Silicon Valley with offices in Neu-Ulm and Berlin, Germany.4.9. Optional Transport Layer Security (TLS)
4.9. Optional Transport Layer Security (TLS) MLE has been working with partner Xiphera to integrate 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. 🌐 www.missinglinkelectronics.com MLE (Missing Link Electronics) is offering technologies and solutions for Domain-Specific Architectures, which focus on heterogeneous computing using FPGAs. MLE is headquartered5.1. FPGA Resource Estimates
5.1. Resource Estimates for AMD Versal AI Edge Series
- 5.1. Resource Estimates for AMD Versal AI Edge Series
- 5.2. Resource Estimates for AMD/Xilinx Ultrascale+ Series
- 5.3. Resource Estimates for AMD/Xilinx 7-Series
- 5.4. Resource Estimates for Altera/Intel Agilex 5E
- 5.5. Resource Estimates for Altera/Intel Stratix-10
- 5.6. Resource Estimates for Lattice Avant-G
- 5.7. Resource Estimates for Microchip Polarfire
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
5.2. Resource Estimates 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
5.3. Resource Estimates for AMD/Xilinx 7-Series
The following table shows resources for AMD/Xilinx 7-Series Kintex fabric (XC7Z045-2) compiled with AMD/Xilinx Vivado 2014.4 – instantiating the following design features:
- 10 GigE Low-Latency MAC from Fraunhofer HHI
- Ethernet block
- IPv4 block
- UDP block
- 2 instances of TCP blocks
- No diagnostics
6. Network Administration for NPAP
6. Network Administration for NPAP
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 NPAP, similar configurations are possible in two distinct ways.
You can parameterize NPAP using a wide range of compile-time parameters in HDL.
Or, you can use run-time parameterization via NPAP’s Python-based software which comprises the NPAP HAL python package and the command-line tool (npap-admin). This software interfaces with the NPAP ERD through a wide range of options such as UART, I2C or PCIe, making it easy to adopt NPAP to your use case (see Section 3.4. 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) the local IPv4 and MAC address is configured on a per NPAP instance and applies to all TCP and UDP sessions within that same NPAP instance.
To demonstrate the simplicity of using NPAP HAL and the Python script npap-admin the following example shows how to configure the IPv4 and MAC address of an NPAP subsystem.
First you write a YAML configuration file as follows:
7. System Verification via RTL Simulation
7. System Verification via RTL Simulation
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
8. Developer Documentation
8. Developer Documentation A comprehensive product design guide and a detailed description of the support IPs and their documentation is available under license: NPAP Product Guide for the KernelDocuments the features, limitations, the configuration parameters and the interfaces of the NPAP Kernel. NPAP Product Guide for the LL-MACDocuments the features, configuration parameter and interfaces for the MLE MAC IP Core running at 10GBit/s or 25Gbit/s line rates NPAP Product Guides for the TCP App TCP Command ApplicationDocuments attributes, ports and AXI4-lite registers of the IP Core responsible for configuring a TCP session in the NPAP Kernel. TCP Demo ApplicationDocuments attributes, ports and AXI4-lite registers of the IP Core responsible for handling the data flow of a TCP session. NPAP Product Guide for the UDP Demo ApplicationDocuments attributes, ports and AXI4-lite registers of the IP Core handling an UDP session. NPAP Product Guide for the Netperf Control ApplicationDocumentation is currently work in progress NPAP Product Guide for the Data Generator / Checker (DGC)Documents everything necessary to include, configure or interact with the data generator and checker in your design. NPAP Product Guide for the Impairment Generator ApplicationDocuments attributes, ports and AXI4-lite registers of the IP core, which can introduce a variable bit-error rate. NPAP User Guide for the Hardware Abstraction Layer (HAL)Documents the9. Changelog
9. Changelog
The following lists MLE’s engineering changelog for 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.
9.1. 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
- TCP
- 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
- all
- NPAP Kernel v2.9.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 – improve code readability and quality
- GENERAL
- ERD v3.4.10
- all
- bump ERD to v3.4.10
- altera_storey_peak_source_full_10g_async_npap2
- #7625 – new ERD 105 for Microsoft Catapult v2 Storey Peak
- IP
- update to NPAP v2.8.1
- update to Netperf v4.0.1
- update to MAC 10GBE v.1.2.1
- all
- NPAP Kernel v2.8.1
10. Detailed Protocol Support (RFC1122 excerpt)
10. Detailed Protocol Support (RFC1122 excerpt)
10.1. 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 |