CONTACT MLE
Please fill in the form and your requirements below, and our team will contact you soon.


    AMD (Xilinx)Altera (Intel)LatticeMicrochip (MicroSemi)Other


    *By submitting this form you are consenting to being contacted by the MLE via email and receiving marketing information.

    X
    CONTACT MLE

    Implementation Details

    Datasheet, NPAP Datasheet
    MLE NPAP Implementation Details Table of Contents MLE NPAP Implementation DetailsMLE NPAP Compile-Time ParametersMLE NPAP Runtime Parameters MLE NPAP implements a full accelerator, hence all network protocol processing is running as digital logic. Because MLE NPAP does not rely on “soft” CPUs nor on external CPUs, MLE NPAP shows very low and deterministic latency. Tradeoff cost vs performance over chip resources. Dataflow is full duplex 128 bits wide using AXI4 Stream. This enables high data throughput without “FPGA bloat” nor timing issues. Control-flow uses AXI4 Lite register interfaces, along with a hardware abstraction layer (HAL), Linux device drivers and Python scripts for MLE NPAP administration. MLE NPAP is intensively tested for performance and interoperability against many other TCP/UDP/IPv4 network stacks. MLE NPAP brings its own 10G / 25G Low-Latency Ethernet MAC,but can interface with many Ethernet subsystems from the FPGA vendors. MLE NPAP implements a complete TCP/UDP/IPv4 stack including functions like ARP, ICMPv4, IGMPv4, DHCP. MLE NPAP is delivered with “Support IP blocks” including reference designs, design examples for setting MAC addresses and/or IPv4 addresses and/or TCP port numbers either from Programmable Logic / ASIC or via software running on a (Linux) host, either ARM or x86 based. For each TCP connection that remains open at the same time, there shall be

    Read More

    Dataflow Block Diagram

    Datasheet, NPAP Datasheet
    MLE NPAP Dataflow Block Diagram The following shows the dataflow view of an exemplary design integrating MLE NPAP with one UDP core and multiple TCP cores (3 for user-level plus 2 for Netperf), each with an example user application, plus Netperf (for bandwidth and latency benchmarking), plus network impairment (for Bit Error Rate Testing), plus diagnostics counters: The example user applications serve as an example on how to send and/or receive data from programmable logic via TCP/UDP/IPv4. For TCP this logic is inside one (or more) TCP Wrappers which contain HDL code for handling the control and data flow: TCA – the TCP Command Application to open/close a TCP connection TDA – the TCP Demo Application which uses the TCA to control the TCP session and can forward data to and from external applications such as the DGC DGC – a Data Generator and Checker which can generate payload data for sending and at the same time can check received payload data Similarly, for UDP this logic is inside the one (or more) UDP Wrappers which contain HDL code for handling the control and data flow: UDA – the UDP Demo Application which handles the control and data flow for one UDP port  DGC – a Data Generator and Checker which can

    Read More

    Control-Flow View

    Datasheet, NPAP Datasheet
    MLE NPAP Control-Flow and Hardware Abstraction Layer Table of Contents MLE NPAP Control-Flow and Hardware Abstraction LayerMLE NPAP Admin via USB-UART or USB-JTAGMLE NPAP Admin via Embedded Processing SystemMLE NPAP Admin via PCIe MLE NPAP Admin via Out-of-Band Ethernet / UDP For administration and control at run-time, MLE NPAP implements so-called Runtime Parameterization and administration via an AXI-Lite register space. Access to this interface is exported through the so-called NPAP Hardware Abstraction Layer (HAL). Along with a Python library, NPAP HAL provides a high-level API for Linux software, utilizing swappable backends to communicate with the hardware across diverse environments, from SOC processing systems to remote workstations. Here a list of connectivity choices for NPAP HAL: Via USB-UART or USB-JTAG or USB-IIC Via the FPGA-integrated Processing System which can be ARM, RISC-V, MicroBlaze, NIOS, etc Via PCIe connection with the host CPU  Via out-of-band Ethernet and UDP (on the roadmap) Via in-band Ethernet and UDP (on the roadmap) Besides NPAP HAL, MLE further provides a python based command-line tool, called npap-admin, that abstracts complex runtime parameterization into simple configuration file editing. Customers have been using npap-admin during evaluation and development, for Continuous Integration or in-the-field when NPAP-based products have been deployed. Good design examples for Runtime parameterization and administration of NPAP are the so-called

    Read More

    Diagnostics and Network Statistics

    Datasheet, NPAP Datasheet
    MLE NPAP Diagnostics and Network Statistics Table of Contents MLE NPAP Diagnostics and Network StatisticsDiagnostics Data Acquisition ModesNetwork Diagnostics Resource Costs In particular at faster line rates, diagnosing network protocol issues can be costly, time-consuming and challenging. Therefore, MLE NPAP comes with specialized diagnostics blocks, providing a powerful suite of tools for in-depth network analysis and efficient troubleshooting of network behavior. These diagnostics are fully optional and offer TCP/UDP/IPv4 layer-specific visibility of counters and status information similar to those in Linux or Windows, for example: TCP Core Activity: Track performance and network usage of individual cores. TCP Peer Balance: Monitor data flow and identify peer misconfigurations. Buffer Optimization: Fine-tune buffer settings using diagnostic data and RTT. General Troubleshooting: Track packets, errors, and pinpoint issue sources. MLE NPAP’s diagnostics blocks are accessed using AXI4-Lite and enable efficient diagnosis and a faster path towards resolving network problems when using hardware acceleration. Diagnostics Data Acquisition Modes The MLE NPAP diagnostics system supports multiple data acquisition modes to cater to different debugging and analysis needs. These modes define how the underlying counter and event state registers are updated. The selected mode applies universally to all readable counter and event state registers within the respective diagnostics block: Continuous Mode Registers the current state of events and counters

    Read More

    Network Impairment (Bit Errors)

    Datasheet, NPAP Datasheet

    MLE NPAP Network Impairment and Bit Error Insertion

    MLE NPAP has an optional integrated Network Impairment Generator. Network Impairment is also known as Bit Error Insertion. This helps to rigorously test and validate the robustness of your network by emulating real-world network impairments, such as Bit Error Rates (BER), at line speed.

    The Ethernet standard requires a BER no higher than 1×10⁻¹². NPAP’s Network Impairment Generator allows you to test your system far beyond this ideal requirement, simulating real-world conditions like those found in high-EMI environments or when using slip rings, for example.

    The Network Impairment Generator IP Core sits on the data path between the TCP/UDP/IPv4 layer and the Ethernet MAC layer, allowing for precise, controlled injection of errors. This enables you to perform stress testing and gain valuable insights into system performance under non-ideal conditions, ensuring your implementation remains resilient against link quality degradation.

    The graph below illustrates how different levels of Bit Error Rate (BER) over a 10 GBit/s link, emulated using NPAP’s Network Impairment Generator, affect the TCP throughput of a TCP connection between two MLE NPAP instances. Obviously, the TCP re-transmissions “eat” into the net data throughput:

    Read More

    System-Level Architecture Aspects

    Datasheet, NPAP Architecture
    MLE NPAP System-Level Architecture Aspects for TCP/UDP/IPv4 Team MLE has gained long and deep experiences when using TCP/UDP/IPv4 for networked and distributed systems and will support you in identifying, implementing and testing the right architecture choice. Key aspects are outlined below: Picking the “Right” TCP Peer Chosing the Right TCP Rx/Tx Buffer Sizes Scaling the Number of TCP Cores Optimize for Linerate Performance Hybrid Acceleration Time-Sensitive Networking (TSN) Linux Kernel Bypass Transport Layer Security (TLS)

    Read More

    Picking the “Right” TCP Peer

    Datasheet, NPAP Architecture
    Picking the “Right” TCP Peer MLE NPAP has a clear focus on highest performance in a very resource efficient FPGA implementation which is reliable (the key reason to use TCP) and interoperable with (almost) any other TCP/UDP/IPv4 stack.  When you optimize data transports towards low latency and/or high bandwidth, keep in mind how both, TCP flow control and TCP congestion control, function and do parameterize both peers accordingly.  MLE NPAP runs the entire protocol stack as a digital circuit. So, when MLE NPAP is on the receiving side, TCP packets will be checked, and acknowledged (ACK’ed), in a very short time and at a very high rate (close to line rate). That may challenge a “slow sender”. Similarly, when MLE NPAP is on the sender side, TCP packets will be generated and sent in a very short time and at a very high rate (close to line rate). That may challenge a “slow receiver”. Experimenting, and tweaking parameters on either side, is key to delivering good performance. Predictable high bandwidth and low latency is typically delivered by a “balanced” TCP connection, for example by putting MLE NPAP on both sides. When implementing so-called High-Speed Data Acquisition systems we do recommend investigating NPAP not only for sensor-side TCP/IPv4 acceleration but also for PC-side:

    Read More

    TCP Rx/Tx Buffer Sizes

    Datasheet, NPAP Architecture
    Chosing the Right TCP Rx/Tx Buffer Sizes Chosing the right TCP Rx/Tx buffer sizes is fundamental to any TCP connection: If the TCP Rx/Tx buffers are undersized, then the TCP throughput may not reach maximum line rate. Hence, in software systems we typically set those TCP Rx/Tx buffers to some large value. However, in a Full Accelerator TCP Tx buffers and TCP Rx buffers require expensive on-chip memory resources. So, we suggest to chose the “right” TCP Rx/Tx buffer sizes. To help you pick a good tradeoff, please use the so-called Bandwidth-Delay Product (BDP) metric to determine TCP buffer sizes for TCP (keep in mind, TCP buffers are placed on both ends: Tx side and Rx side): Buffer size (in bits) = Bandwidth (in bits-per-second) * RTT (in seconds) RTT is the Round-Trip Time which is the time for the sender to transmit the data plus the time-of-flight for the data, plus the time it takes the recipient to check for packet correctness (CRC), plus the time for the recipient to send out the ACK, plus the time-of-flight for the ACK, plus the time it takes the sender to process the ACK and release the buffer. Here examples: Assuming a direct connection with the recipient being MLE NPAP, and a 25 GBit/s

    Read More

    Scaling the Number of TCP Cores

    Datasheet, NPAP Architecture
    Scaling the Number of TCP Cores Table of Contents Scaling the Number of TCP CoresEffects of On-Chip Routing:Effects of TCP Bandwidth Sharing:Multiple MLE NPAP Subsystems with a Separate IPv4 Addresses:Hybrid Acceleration: In typical software systems, the cost of opening a TCP connection is quite CPU expensive, and may take a long time because of RTT and processing times in the operating system. Therefore, most software driven systems keep a TCP connection alive “forever” rather than closing it. In software, the low costs of system RAM for storing each TCP connection’s state are not worth the CPU processing costs. For MLE NPAP, each TCP connection which is open at the same time requires a dedicated TCP Core – which costs FPGA / ASIC resources. However, if RTT is low such as in a LAN, and with the very low costs of opening and closing a TCP connection in MLE NPAP (a few hundred FPGA clock cycles), “time sharing” TCP Cores can save a lot of FPGA resources without any negatives. Please refer to the MLE Technical Brief TB20201203 “Deterministic Networking with TSN-10/25/50/100G” for more information on “time sharing” TCP Cores. Deterministic Networking with TSN-10/25/50/100G Effects of On-Chip Routing: Typically, FPGA routing is a key limiting factor: The more TCP Cores you instantiate, the

    Read More

    Optimize for Performance

    Datasheet, NPAP Architecture
    Optimize MLE NPAP for Performance Scaling performance for MLE NPAP is like any on-chip full accelerator: The wider the datapaths and the higher clock speed the better the throughput. ASIC implementations can clock at 1 GHz, or faster (depends on with ASIC process you will be using) and power is not so much of an issue because MLE NPAP can be quite small (typ. less then 200k gates). For FPGAs, however, things are different, clock frequencies above 500 MHz may be hard to achieve. MLE is constantly working with FPGA vendors to improve MLE NPAP clock frequency. While MLE NPAP originally was designed for ASIC implementation, MLE has adopted MLE NPAP for efficient implementation using modern FPGA fabric. Unlike other TCP stacks for FPGA, MLE NPAP features a 128 bit wide bi-directional datapath which puts MLE NPAP into a unique position for realizing high-bandwidth FPGA-based SmartNICs without “FPGA bloat”.  Larger bit widths, 512 bits or more, cause “FPGA bloat” which is wasting FPGA resources. Smaller bit widths, 64 bits or less, do require unrealistic high clock frequencies to deliver high line rates as the following table shows:   10 Gbps 25 Gbps 50 Gbps 100 Gbps 32 bit 312.5 MHz 781.25 MHz 1,562.5 MHz 3,125.0 MHz 64 bits 156.25 MHz 390.625 MHz

    Read More