Low Latency 40-Gbps Ethernet IP Core User Guide

ID 683745
Date 3/08/2021
Public
Document Table of Contents
Give Feedback

2.8.1. Testbench Behavior

The non-40GBASE-KR4 testbenches send traffic through the IP core in transmit-to-receive loopback mode, exercising the transmit side and receive side of the IP core in the same data flow. These testbenches send traffic to allow the Ethernet lanes to lock, and then send packets to the transmit client data interface and check the data as it returns through the receive client data interface.

The 40GBASE-KR4 testbench sends traffic through the two IP cores in each direction, exercising the receive and transmit sides of both IP cores. This testbench exercises auto-negotiation and link training, and then sends and checks packets in data mode.

Figure 8.  LL 40GbE non-40GBASE-KR4 IP Core Testbench The top-level testbench file consists of a simple packet generator and checker and one IP core in a loopback configuration.
Figure 9. 40GBASE-KR4 LL 40GbE IP Core TestbenchTo support the simulation of auto-negotiation, the testbench for 40GBASE-KR4 variations uses two instances of the IP core instead of configuring the IP core in loopback mode. For each IP core there is a packet generator to send traffic on the TX side of the IP core and a packet checker to check the packets it receives from the other IP core. The two IP cores communicate with each other through their Ethernet link, in which the testbench injects random skew. The 40GBASE-KR4 testbench connects each IP core to a transceiver TX PLL, and exercises auto-negotiation, link training, and data mode.
Figure 10. Typical LL 40GbE Traffic on the Avalon-ST InterfaceShows typical traffic from the simulation testbench created using the run_vsim.do script in ModelSim. In Stratix V variations the script is found in <instance_name> _example_design/alt_eth_ultra/example_testbench/run_vsim.do and in Arria 10 variations the script is found in <example_design_directory> /example_testbench/run_vsim.do.
Note: Client logic must maintain the l4_tx_valid signal asserted while asserting SOP, through the assertion of EOP. Client logic should not pull this signal low during a packet transmission.

The markers in the figure show the following sequence of events:

  1. At marker 1, the application asserts l4_tx_startofpacket, indicating the beginning of a TX packet.
  2. At marker 2, the application asserts l4_tx_endofpacket, indicating the end of the TX packet. The value on l4_tx_empty[4:0] indicates that the 2 least significant bytes of the last data cycle are empty.
  3. At marker 3, the IP core asserts l4_rx_startofpacket, indicating the beginning of an RX packet. A second transfer has already started on the TX bus.
  4. At marker 4, the 40GbE IP core deasserts l4_rx_valid, indicating that the IP core does not have new valid data to send to the client on l4_rx_data[255:0]. l4_rx_data[255:0] remains unchanged for a second cycle, but because the l4_rx_valid signal is deasserted, the client should ignore the value on the RX signals.
  5. A marker 5, the 40GbE IP core asserts l4_rx_valid, indicating that it has valid data to send to the client on l4_rx_data[255:0].
  6. At marker 6, the 40GbE IP core deasserts l4_rx_valid, indicating that it does not have new valid data to send to the client on l4_rx_data[255:0]. l4_rx_data[255:0] remains unchanged for a second cycle.
  7. At marker 7, the 40GbE IP core asserts l4_rx_valid, indicating that it has valid data to send to the client on l4_rx_data[255:0].
  8. At marker 8, the 40GbE IP core deasserts l4_rx_valid, indicating that the 40GbE IP core does not have new valid data to send to the client on l4_rx_data[255:0]. l4_rx_data[255:0] remains unchanged for a second cycle.
  9. At marker 9, the IP core asserts l4_rx_endofpacket, indicating the end of the RX packet. l4_rx_empty[4:0] has a value of 0x1D, indicating that 29 least significant bytes of the last cycle of the RX packet empty.
Note: The ready latency on the Avalon-ST TX client interface is 0.