Low Latency 40- and 100-Gbps Ethernet MAC and PHY MegaCore Function User Guide

ID 683628
Date 12/28/2017
Public
Document Table of Contents

2.8.1. Low Latency 40-100GbE IP Core Testbench Overview

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.

Figure 7. Low Latency 40-100GbE non-40GBASE-KR4 IP Core Testbench Illustrates the top-level modules of the Low Latency 40GbE and 100GbE example testbenches.
Figure 8. 40GBASE-KR4 LL 40GbE IP Core TestbenchIllustrates the top-level modules of the LL 40GBASE-KR4 example testbench. To support the simulation of auto-negotiation, the testbench uses two instances of the IP core instead of configuring the IP core in loopback mode.
Table 15.  Low Latency 40-100GbE IP Core Testbench File DescriptionsLists the key files that implement the example testbenches.

File Names

Description

Testbench and Simulation Files

basic_avl_tb_top.v Top-level testbench file for non-40GBASE-KR4 variations. The testbench instantiates the DUT and runs Verilog HDL tasks to generate and accept packets.
alt_e40_avalon_kr4_tb.sv Top-level testbench file for 40GBASE-KR4 variations.
alt_e40_avalon_tb_packet_gen.v, alt_e40_avalon_tb_packet_gen_sanity_check.v, alt_e40_stat_cntr_1port.v Packet generator and checkers for 40GBASE-KR4 variations.

Testbench Scripts

run_vsim.do

The ModelSim script to run the testbench.

run_vcs.sh

The Synopsys VCS script to run the testbench.

run_ncsim.sh

The Cadence NCSim script to run the testbench.

Figure 9. Typical 40GbE Traffic on the Avalon-ST InterfaceShows typical traffic from the simulation testbench created using the run_vsim.do script in ModelSim. In this case the IP core is a 40GbE IP core with adapters. 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.